# HG changeset patch # User jlarmour # Date 1022194791 0 # Node ID d2c90368aeef0e28409aaaa67420c9f08c4d29c5 # Parent 19edcb2e78cce3121b262ab53d99426dee19ed1f Merge from eCos master repository on 2002-05-23-21:39:14-BST diff --git a/host/libcdl/doc/advanced.sgml b/host/libcdl/doc/advanced.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/advanced.sgml @@ -0,0 +1,60 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Templates, Targets and Other Topics + + +Templates + +This section is still under construction. + + + + +Targets + +This section is still under construction. + + + + \ No newline at end of file diff --git a/host/libcdl/doc/build.sgml b/host/libcdl/doc/build.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/build.sgml @@ -0,0 +1,2145 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +The Build Process + + + + +Some &CDL; properties describe the consequences of manipulating +configuration options. There are two main types of consequences. +Typically enabling a configuration option results in one or more +#define's in a configuration header file, and +properties that affect this include &define;, &define-proc; and +&no-define;. Enabling a configuration option can also affect the build +process, primarily determining which files get built and added to the +appropriate library. Properties related to the build process include +&compile; and &make;. This chapter describes the whole build process, +including details such as compiler flags and custom build steps. + + +Part of the overall design of the &eCos; component framework is that +it can interact with a number of different build systems. The most +obvious of these is GNU +make:the component framework can generate one or more +makefiles, and the user can then build the various packages simply by +invoking make. However it +should also be possible to build &eCos; by other means: the +component framework can be queried about what is involved in building +a given configuration, and this information can then be fed into the +desired build system. Component writers should be aware of this +possibility. Most packages will not be affected because the &compile; +property can be used to provide all the required information, but care +has to be taken when writing custom build steps. + + + + + + +Build Tree Generation + + +It is necessary to create an &eCos; configuration before anything can +be built. With some tools such as the graphical configuration tool +this configuration will be created in memory, and it is not essential +to produce an ecos.ecc savefile first (although +it is still very desirable to generate such a savefile at some point, +to allow the configuration to be re-loaded later on). With other tools +the savefile is generated first, for example using +ecosconfig new, and then a build tree is +generated using ecosconfig tree. The savefile +contains all the information needed to recreate a configuration. + + +An &eCos; build actually involves three separate trees. The component +repository acts as the source tree, and for application developers +this should be considered a read-only resource. The build tree is +where all intermediate files, especially object files, are created. +The install tree is where the main library +libtarget.a, the exported header files, and +similar files end up. Following a successful build it is possible to +take just the install tree and use it for developing an application: +none of the files in the component repository or the build tree are +needed for that. The build tree will be needed again only if the user +changes the configuration. However the install tree does not contain +copies of all of the documentation for the various packages, instead +the documentation is kept only in the component repository. + + +By default the build tree, the install tree, and the +ecos.ecc savefile all reside in the same +directory tree. This is not a requirement, both the install tree and +the savefile can be anywhere in the file system. + + +It is worth noting that the component framework does not separate the +usual make and make install +stages. A build always populates the install tree, and any +make install step would be redundant. + + +The install tree will always begin with two directories, include for the exported header files and +lib for the main library +libtarget.a and other files +such as the linker script. In addition there will be a subdirectory +include/pkgconf containing the +configuration header files, which are generated or updated at the same +time the build tree is created or updated. More details of header file +generation are given below. Additional include subdirectories such as sys and cyg/kernel will be created during the +first build, when each package's exported header files are copied to +the install tree. The install tree may also end up with additional +subdirectories during a build, for example as a result of custom build +steps. + + +The component framework does not define the structure of the build +tree, and this may vary between build systems. It can be assumed that +each package in the configuration will have its own directory in the +build tree, and that this directory will be used for storing the +package's object files and as the current directory for any build +steps for that package. This avoids problems when custom build steps +from different packages generate intermediate files which happen to +have the same name. + + +Some build systems may allow application developers to copy a source +file from the component repository to the build tree and edit the +copy. This allows users to experiment with small changes, for example +to add a couple of lines of debugging to a package, without having to +modify the master copy in the component repository which could be +shared by several projects or several people. Functionality such as +this is transparent to component writers, and it is the responsibility +of the build system to make sure that the right thing happens. + + + + +There are some unresolved issues related to the build tree and install +tree. Specifically, when updating an existing build or install tree, +what should happen to unexpected files or directories? Suppose the +user started with a configuration that included the math library, and +the install tree contains header files include/math.h and include/sys/ieeefp.h. The user then removed +the math library from the configuration and is updating the build +tree. It is now desirable to remove these header files from the +install tree, so that if any application code still attempts to use +the math library this will fail at compile time rather than at link +time. There will also be some object files in the existing +libtarget.a library which are no longer +appropriate, and there may be other files in the install tree as a +result of custom build steps. The build tree will still contain a +directory for the math library, which no longer serves any purpose. + + +However, it is also possible that some of the files in the build tree +or the install tree were placed there by the user, in which case +removing them automatically would be a bad idea. + + +At present the component framework does not keep track of exactly what +should be present in the build and install trees, so it cannot readily +determine which files or library members are obsolete and can safely +be removed, and which ones are unexpected and need to be reported to +the user. This will be addressed in a future release of the system. + + + + + + + + + +Configuration Header File Generation + + +Configuration options can affect a build in two main ways. First, +enabling a configuration option or other &CDL; entity can result in +various files being built and added to a library, thus providing +functionality to the application code. However this mechanism can only +operate at a rather coarse grain, at the level of entire source files. +Hence the component framework also generates configuration header +files containing mainly C preprocessor #define +directives. Package source code can then #include +the appropriate header files and use #if, +#ifdef and #ifndef directives to +adapt accordingly. In this way configuration options can be used to +enable or disable entire functions within a source file or just a +single line, whichever is appropriate. + + +The configuration header files end up in the include/pkgconf subdirectory of the +install tree. There will be one header file for the system as a whole, +pkgconf/system.h, and there will +be additional header files for each package, for example +pkgconf/kernel.h. The header files +are generated when creating or updating the build and install trees, +which needs to happen after every change to the configuration. + + +The component framework processes each package in the configuration +one at a time. The exact order in which the packages are processed is +not defined, so the order in which #define's will +end up in the global pkgconf/system.h header may vary. However +for any given configuration the order should remain consistent until +packages are added to or removed from the system. This avoids +unnecessary changes to the global header file and hence unnecessary +rebuilds of the packages and of application code because of header +file dependency handling. + + +Within a given package the various components, options and interfaces +will be processed in the order in which they were defined in the +corresponding &CDL; scripts. Typically the data in the configuration +headers consists only of a sequence of #define's so +the order in which these are generated is irrelevant, but some +properties such as &define-proc; can be used to add arbitrary data to +a configuration header and hence there may be dependencies on the +order. It should be noted that re-parenting an option below some other +package has no effect on which header file will contain the +corresponding #define: the preprocessor directives +will always end up in the header file for the package that defines the +option, or in the global configuration header. + + +There are six properties which affect the process of generating header +files: +&define-header;, +&no-define;, +&define-format;, +&define;, +&if-define;, and +&define-proc;. + + +The &define-header; property can only occur in the body of a +&cdl-package; command and specifies the name of the header file which +should contain the package's configuration data, for example: + + +cdl_package <some_package> { + … + define_header xyzzy.h +} + + +Given such a &define-header; property the component framework will +use the file pkgconf/xyzzy.h for +the package's configuration data. If a package does not have +a &define-header; property then a suitable file name is constructed +from the package's name. This involves: + + + + +All characters in the package name up to and including the first +underscore are removed. For example CYGPKG_KERNEL +is converted to KERNEL, and +CYGPKG_HAL_ARM is converted to +HAL_ARM. + + + + +Any upper case letters in the resulting string will be converted to +lower case, yielding e.g. kernel and +hal_arm. + + + + +A .h suffix is appended, yielding e.g. +kernel.h and hal_arm.h. + + + + +Because of the naming restrictions on configuration options, this +should result in a valid filename. There is a small possibility of a +file name class, for example CYGPKG_PLUGH and +CYGPKG_plugh would both end up trying to use the +same header file pkgconf/plugh.h, +but the use of lower case letters for package names violates the +naming conventions. It is not legal to use the &define-header; +property to put the configuration data for several packages in a +single header file. The resulting behaviour is undefined. + + +Once the name of the package's header file has been determined and the +file has been opened, the various components, options and interfaces +in the package will be processed starting with the package itself. The +following steps are involved: + + + + +If the current option or other &CDL; entity is inactive or disabled, +the option is ignored for the purposes of header file generation. +#define's are only generated for options that are +both active and enabled. + + + + +The next step is to generate a default #define for +the current option. If this option has a &no-define; property then the +default #define is suppressed, and processing +continues for &define;, &if-define; and &define-proc; properties. + + + + +The header file appropriate for the default #define +is determined. For a &cdl-package; this will be pkgconf/system.h, for any other option this +will be the package's own header file. The intention here is that +packages and application code can always determine which packages are +in the configuration by #include'ing pkgconf/system.h. The C preprocessor lacks +any facilities for including a header file only if it exists, and +taking appropriate action otherwise. + + + + +For options with the flavors bool or +none, a single #define will be +generated. This takes the form: + + +#define <option> 1 + + +For example: + + +#define CYGFUN_LIBC_TIME_POSIX 1 + + +Package source code can check whether or not an option is active and +enabled by using the #ifdef, +#ifndef or #if +defined(…)directives. + + + + +For options with the flavors data or +booldata, either one or two +#define's will be generated. The first of these may +be affected by a &define-format; property. If this property is not +defined then the first #define will take the form: + + +#define <option> <value> + + +For example: + + +#define CYGNUM_LIBC_ATEXIT_HANDLERS 32 + + +Package source code can examine this value using the +#if directive, or by using the symbol in +code such as: + + + for (i = 0; i < CYGNUM_LIBC_ATEXIT_HANDLERS; i++) { + … + } + + +It must be noted that the #define will be generated +only if the corresponding option is both active and enabled. Options +with the data flavor are always enabled but may not +be active. Code like the above should be written only if it is known +that the symbol will always be defined, for example if the +corresponding source file will only get built if the containing +component is active and enabled. Otherwise the use of additional +#ifdef or similar directives will be necessary. + + + + +If there is a &define-format; property then this controls how the +option's value will appear in the header file. Given a format string +such as %08x and a value 42, the component +framework will execute the &Tcl; command +format %08x 42 and the result will be +used for the #define's value. It is the +responsibility of the component writer to make sure that this &Tcl; +command will be valid given the format string and the legal values for +the option. + + + + +In addition a second #define may or may not be +generated. This will take the form: + + +#define <option>_<value> + + +For example: + + +#define CYGNUM_LIBC_ATEXIT_HANDLERS_32 + + +The #define will be generated only if it would +result in a valid C preprocessor symbol. If the value is a string such +as "/dev/ser0" then the #define +would be suppressed. This second #define is not +particularly useful for numerical data, but can be valuable in other +circumstances. For example if the legal values for an option +XXX_COLOR are red, +green and blue then code like +the following can be used: + + +#ifdef XXX_COLOR_red + … +#endif +#ifdef XXX_COLOR_green + … +#endif +#ifdef XXX_COLOR_blue + … +#endif + + +The expression syntax provided by the C preprocessor is limited to +numerical data and cannot perform string comparisons. By generating +two #define's in this way it is possible to work +around this limitation of the C preprocessor. However some care has to +be taken: if a component writer also defined a configuration option +XXX_COLOR_green then there will be confusion. Since +such a configuration option violates the naming conventions, the +problem is unlikely to arise in practice. + + + + + + + +For some options it may be useful to generate one or more additional +#define's or, in conjunction with the &no-define; +property, to define a symbol with a name different from the option's +name. This can be achieved with the &define; property, which takes the +following form: + + + define [-file=<filename>] [-format=<format>] <symbol> + + +For example: + + + define FOPEN_MAX + + +This will result in something like: + + +#define FOPEN_MAX 8 +#define FOPEN_MAX_8 + + +The specified symbol must be a valid C preprocessor symbol. Normally +the #define will end up in the same header file as +the default one, in other words pkgconf/system.h in the case of a +&cdl-package;, or the package's own header file for any other option. +The -file option can be used to change this. At +present the only legal value is system.h, for +example: + + + define -file=system.h <symbol> + + +This will cause the #define to end up in the global +configuration header rather than in the package's own header. Use of +this facility should be avoided since it is very rarely necessary to +make options globally visible. + + +The &define; property takes another option, +-format, to provide a format string. + + + define -format=%08x <symbol> + + +This should only be used for options with the data +or booldata flavor, and has the same effect as the +&define-format; property has on the default +#define. + + +&define; properties are processed in the same way the default +#define. For options with the +bool or none flavors a single +#define will be generated using the value +1. For options with the data or +booldata flavors either one or two +#define's will be generated. + + + + + +After processing all &define; properties, the component framework will +look for any &if-define; properties. These take the following form: + + + if_define [-file=<filename>] <symbol1> <symbol2> + + +For example: + + + if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS + + +The following will be generated in the configuration header file: + + +#ifdef CYGSRC_KERNEL +# define CYGDBG_USE_ASSERTS +#endif + + +Typical kernel source code would begin with the following construct: + + +#define CYGSRC_KERNEL 1 +#include <pkgconf/kernel.h> +#include <cyg/infra/cyg_ass.h> + + +The infrastructure header file cyg/infra/cyg_ass.h only checks for symbols +such as CYGDBG_USE_ASSERTS, and has no special +knowledge of the kernel or any other package. The &if-define; property +will only affect code that defines the symbol +CYGSRC_KERNEL, so typically only kernel source +code. If the option is enabled then assertion support will be enabled +for the kernel source code only. If the option is inactive or disabled +then kernel assertions will be disabled. Assertions in other packages +are not affected. Thus the &if-define; property allows control over +assertions, tracing, and similar facilities at the level of individual +packages, or at finer levels such as components or even single source +files if desired. + + + +Current &eCos; packages do not yet make use of this facility. Instead +there is a single global configuration option +CYGDBG_USE_ASSERTS which is used to enable or +disable assertions for all packages. This issue should be addressed in +a future release of the system. + + + +As with the &define; property, the &if-define; property takes an +option -file with a single legal value +system.h. This allows the output to be redirected +to pkgconf/system.h if and when +necessary. + + + + + +The final property that is relevant to configuration header file +generation is &define-proc;. This takes a single argument, a &Tcl; +fragment that can add arbitrary data to the global header pkgconf/system.h and to the package's own +header. When the &define-proc; script is invoked two variables will be +set up to allow access to these headers: cdl_header +will be a channel to the package's own header file, for example +pkgconf/kernel.h; +cdl_system_header will be a channel to pkgconf/system.h. A typical &define-proc; +script will use the &Tcl; puts command to output +data to one of these channels, for example: + + +cdl_option <name> { + … + define_proc { + puts $::cdl_header "#define XXX 1" + } +} + + + +In the current implementation the use of &define-proc; is limited +because the &Tcl; script cannot access any of the configuration data. +Therefore the script is limited to writing constant data to the +configuration headers. This is a major limitation which will be +addressed in a future release of the component framework. + + + + + + + + + +Generating C header files with #define's for the +configuration data suffices for existing packages written in some +combination of C, C++ and assembler. It can also be used in +conjunction with some other languages, for example by first passing +the source code through the C preprocessor and feeding the result into +the appropriate compiler. In future versions of the component +framework additional programming languages such as Java may be +supported, and the configuration data may also be written to files in +some format other than C preprocessor directives. + + + + + +At present there is no way for application or package source code to +get hold of all the configuration details related to the current +hardware. Instead that information is spread over various different +configuration headers for the HAL and device driver packages, with +some of the information going into pkgconf/system.h. It is possible that in +some future release of the system there will be another global +configuration header file pkgconf/hardware.h which either contains the +configuration details for the various hardware-specific packages or +which #include's all the hardware-specific +configuration headers. The desirability and feasibility of such a +scheme are still to be determined. To avoid future incompatibility +problems as a result of any such changes, it is recommended that all +hardware packages (in other packages containing the &hardware; +property) use the &define-header; property to specify explicitly which +configuration header should be generated. + + + + +The <filename class="headerfile">system.h</filename> Header + + +Typically configuration header files are #include'd +only by the package's source code at build time, or by a package's +exported header files if the interface provided by the package may be +affected by a configuration option. There should be no need for +application code to know the details of individual configuration +options, instead the configuration should specifically meet the needs +of the application. + + +There are always exceptions. Application code may want to adapt to +configuration options, for example to do different things for ROM and +RAM booting systems, or when it is necessary to support several +different target boards. This is especially true if the code in question +is really re-usable library code which has not been converted to an +eCos package, and hence cannot use any CDL facilities. + + +A major problem here is determining which packages are in the +configuration: attempting to #include a header file +such as pkgconf/net.h +when it is not known for certain that that particular package is part +of the configuration will result in compilation errors. The global +header file pkgconf/system.h +serves to provide such information, so application code can use +techniques like the following: + + + +#include <pkgconf/system.h> +#ifdef CYGPKG_NET +# include <pkgconf/net.h> +#endif + + + +This will compile correctly irrespective of the eCos configuration, +and subsequent code can use #ifdef or similar +directives on CYGPKG_NET or any of the +configuration options in that package. + + +In addition to determining whether or not a package is present, the +global configuration header file can also be used to find out the +specific version of a package that is being used. This can be useful +if a more recent version exports additional functionality. It may also +be necessary to adapt to incompatible changes in the exported +interface or to changes in behaviour. For each package the +configuration system will typically #define three +symbols, for example for a V1.3.1 release: + + +#define CYGNUM_NET_VERSION_MAJOR 1 +#define CYGNUM_NET_VERSION_MINOR 3 +#define CYGNUM_NET_VERSION_RELEASE 1 + + +There are a number of problems associated with such version +#define's. The first restriction is that the +package must follow the standard naming conventions, so the package +name must be of the form xxxPKG_yyy. The three +characters immediately preceding the first underscore must be +PKG, and will be replaced with +NUM when generating the version +#define's. If a package does not follow the naming +convention then no version #define's will be +generated. + + +Assuming the package does follow the naming conventions, the +configuration tools will always generate three version +#define's for the major, minor, and release +numbers. The symbol names are obtained from the package name by +replacing PKG with NUM and +appending _VERSION_MAJOR, +_VERSION_MINOR and +_VERSION_RELEASE. It is assumed that the resulting +symbols will not clash with any configuration option names. The values +for the #define's are determined by searching the +version string for sequences of digits, optionally preceded by a minus +sign. It is possible that some or all of the numbers are absent in any +given version string, in which case -1 will be used +in the #define. For example, given a version string +of V1.12beta, the major version number is +1, the minor number is 12, and +the release number is -1. Given a version string of +beta all three numbers would be set to +-1. + + +There is special case code for the version current, +which typically corresponds to a development version obtained via +anonymous CVS or similar means. The configuration system has special +built-in knowledge of this version, and will assume it is more recent +than any specific release number. The global configuration header +defines a special symbol CYGNUM_VERSION_CURRENT, +and this will be used as the major version number when version +current of a package is used: + + +#define CYGNUM_VERSION_CURRENT 0x7fffff00 +... +#define CYGNUM_INFRA_VERSION_MAJOR CYGNUM_VERSION_CURRENT +#define CYGNUM_INFRA_VERSION_MINOR -1 +#define CYGNUM_INFRA_VERSION_RELEASE -1 + + + +The large number used for CYGNUM_VERSION_CURRENT +should ensure that major version comparisons work as expected, while +still allowing for a small amount of arithmetic in case that proves +useful. + + +It should be noted that this implementation of version +#define's will not cope with all version number +schemes. However for many cases it should suffice. + + + + + + + + + + +Building eCos + + + + +The primary goal of an eCos build is to produce the library +libtarget.a. A typical &eCos; build will also +generate a number of other targets: extras.o, +startup code vectors.o, and a linker script. Some +packages may cause additional libraries or targets to be generated. +The basic build process involves a number of different phases with +corresponding priorities. There are a number of predefined priorities: + + + + + + + + Priority + Action + + + + + 0 + Export header files + + + 100 + Process &compile; properties + + + + and most &make-object; custom build steps + + + 200 + Generate libraries + + + 300 + Process &make; custom build steps + + + + + + +Generation of the extras.o file, the startup code +and the linker script actually happens via &make; custom build steps, +typically defined in appropriate HAL packages. The component framework +has no special knowledge of these targets. + + +By default custom build steps for a &make-object; property happen +during the same phase as most compilations, but this can be changed +using a -priority option. Similarly custom build +steps for a &make; property happen at the end of a build, but this can +also be changed with a -priority option. For +example a priority of 50 can be used to run a custom build step +between the header file export phase and the main compilation phase. +Custom build steps are discussed in more detail below. + + +Some build systems may run several commands of the same priority in +parallel. For example files listed in &compile; properties may get +compiled in parallel, concurrently with &make-object; custom build +steps with default priorities. Since most of the time for an &eCos; +build involves processing &compile; properties, this allows builds to +be speeded up on suitable host hardware. All build steps for a given +phase will complete before the next phase is started. + + + + + + +Updating the Build Tree + + +Some build systems may involve a phase before the header files get +exported, to update the build and install trees automatically when +there has been a change to the configuration savefile +ecos.ecc. This is useful mainly for application +developers using the command line tools: it would allow users to +create the build tree only once, and after any subsequent +configuration changes the tree would be updated automatically by the +build system. The facility would be analogous to the +--enable-maintainer-mode option provide by the +autoconf and automake programs. At present no &eCos; +build system implements this functionality, but it is likely to be +added in a future release. + + + + + + + + +Exporting Public Header Files + + +The first compulsory phase involves making sure that there is an up to +date set of header files in the install tree. Each package can contain +some number of header files defining the exported interface. +Applications should only use exported functionality. A package can +also contain some number of private header files which are only of +interest to the implementation, and which should not be visible to +application code. The various packages that go into a particular +configuration can be spread all over the component repository. In +theory it might be possible to make all the exported header files +accessible by having a lengthy -I header file +search path, but this would be inconvenient both for building eCos and +for building applications. Instead all the relevant header files are +copied to a single location, the include subdirectory of the install tree. +The process involves the following: + + + + + +The install tree, for example /usr/local/ecos/install, and its include subdirectory /usr/local/ecos/install/include will typically be +created when the build tree is generated or updated. At the same time +configuration header files will be written to the pkgconf subdirectory, for example +/usr/local/ecos/include/pkgconf, so that +the configuration data is visible to all the packages and to +application code that may wish to examine some of the configuration +options. + + + + +Each package in the configuration is examined for exported header +files. The exact order in which the packages are processed is not +defined, but should not matter. + + + + +If the package has an &include-files; property then this +lists all the exported header files: + + +cdl_package <some_package> { + … + include_files header1.h header2.h +} + + +If no arguments are given then the package does not export any header +files. + + +cdl_package <some_package> { + … + include_files +} + + +The listed files may be in an include subdirectory within the package's +hierarchy, or they may be relative to the package's toplevel +directory. The &include-files; property is intended mainly for very +simple packages. It can also be useful when converting existing code +to an &eCos; package, to avoid rearranging the sources. + + + + +If there is no &include-files; property then the component framework +will look for an include +subdirectory in the package, as per the layout conventions. All files, +including those in subdirectories, will be treated as exported header +files. For example, the math library package contains files include/math.h and include/sys/ieeefp.h, both of which will +be exported to the install tree. + + + + +As a last resort, if there is neither an &include-files; property nor +an include subdirectory, the +component framework will search the package's toplevel directory and +all of its subdirectories for files with one of the following +suffixes: .h, .hxx, +.inl or .inc. All such files +will be interpreted as exported header files. + + +This last resort rule could cause confusion for packages which have no +exported header files but which do contain one or more private header +files. For example a typical device driver simply implements an +existing interface rather than define a new one, so it does not need +to export a header file. However it may still have one or more private +header files. Such packages should use an &include-files; property +with no arguments. + + + + + + +If the package has one or more exported header files, the next step is +to determine where the files should end up. By default all exported +header files will just end up relative to the install tree's include subdirectory. For example the +math library's math.h header +would end up as /usr/local/ecos/include/math.h, +and the sys/ieeefp.h header +would end up as +/usr/local/ecos/include/sys/ieeefp.h. This +behaviour is correct for packages like the C library where the +interface is defined by appropriate standards. For other packages this +behaviour can lead to file name clashes, and the &include-dir; property should be used +to avoid this: + + +cdl_package CYGPKG_KERNEL { + include_dir cyg/kernel +} + + +This means that the kernel's exported header file +include/kapi.h should be copied to +/usr/local/ecos/include/cyg/kernel/kapi.h, where +it is very unlikely to clash with a header file from some other +package. + + + + +For typical application developers there will be little or no need for +the installed header files to change after the first build. Changes +will be necessary only if packages are added to or removed from the +configuration. For component writers, the build system should detect +changes to the master copy of the header file source code and update +the installed copies automatically during the next build. The build +system is expected to perform a header file dependency analysis, so +any source files affected should get rebuilt as well. + + + + +Some build systems may provide additional support for application +developers who want to make minor changes to a package, especially for +debugging purposes. A header file could be copied from the +component repository (which for application developers is assumed to +be a read-only resource) into the build tree and edited there. The +build system would detect a more recent version of such a header file +in the build tree and install it. Care would have to be taken to +recover properly if the modified copy in the build tree is +subsequently removed, in order to revert to the original behaviour. + + + + +When updating the install tree's include subdirectory, the build tree may +also perform a clean-up operation. Specifically, it may check for any +files which do not correspond to known exported header files and +delete them. + + + + + +At present there is no defined support in the build system for +defining custom build steps that generate exported header files. Any +attempt to use the existing custom build step support may fall foul of +unexpected header files being deleted automatically by the build +system. This limitation will be addressed in a future release of the +component framework, and may require changing the priority for +exporting header files so that a custom build step can happen first. + + + + + + + + +Compiling + + +Once there are up to date copies of all the exported header files in +the build tree, the main build can proceed. Most of this involves +compiling source files listed in &compile; properties in the &CDL; +scripts for the various packages, for example: + + +cdl_package CYGPKG_ERROR { + display "Common error code support" + compile strerror.cxx + … +} + + +&compile; properties may appear in the body of a &cdl-package;, +&cdl-component;, &cdl-option; or &cdl-interface;. If the option or +other &CDL; entity is active and enabled, the property takes effect. +If the option is inactive or disabled the property is ignored. It is +possible for a &compile; property to list multiple source files, and +it is also possible for a given &CDL; entity to contain multiple +&compile; properties. The following three examples are equivalent: + + +cdl_option <some_option> { + … + compile file1.c file2.c file3.c +} + +cdl_option <some_option> { + … + compile file1.c + compile file2.c + compile file3.c +} + +cdl_option <some_option> { + … + compile file1.c file2.c + compile file3.c +} + + +Packages that follow the directory layout conventions should have a +subdirectory src, and the +component framework will first look for the specified files there. +Failing that it will look for the specified files relative to the +package's root directory. For example if a package contains a source +file strerror.cxx then the following two lines +are equivalent: + + + compile strerror.cxx + compile src/strerror.cxx + + +In the first case the component framework will find the file +immediately in the packages src +subdirectory. In the second case the framework will first look for a +file src/src/strerror.cxx, and then for +str/strerror.cxx relative to the package's root +directory. The result is the same. + + +The file names may be relative paths, allowing the source code to be +split over multiple directories. For example if a package contains a +file src/sync/mutex.cxx then the corresponding +&CDL; entry would be: + + + compile sync/mutex.cxx + + +All the source files relevant to the current configuration will be +identified when the build tree is generated or updated, and added to +the appropriate makefile (or its equivalent for other build systems). +The actual build will involve a rule of the form: + + +<object file> : <source file> + $(CC) -c $(INCLUDE_PATH) $(CFLAGS) -o $@ $< + + + +The component framework has built-in knowledge for processing source +files written in C, C++ or assembler. These should have a +.c, .cxx and +.S suffix respectively. The current implementation +has no simple mechanism for extending this with support for other +languages or for alternative suffixes, but this should be addressed in +a future release. + + +The compiler command that will be used is something like +arm-elf-gcc. This consists of a command prefix, in +this case arm-elf, and a specific command such as +gcc. The command prefix will depend on the target +architecture and is controlled by a configuration option in the +appropriate HAL package. It will have a sensible default value for the +current architecture, but users can modify this option when necessary. +The command prefix cannot be changed on a per-package basis, since +it is usually essential that all packages are built with a consistent +set of tools. + + +The $(INCLUDE_PATH) header file search path +consists of at least the following: + + + + +The include directory in the +install tree. This allows source files to access the various header +files exported by all the packages in the configuration, and also the +configuration header files. + + + + +The current package's root directory. This ensures that all files in +the package are accessible at build time. + + + + +The current package's src +subdirectory, if it is present. Generally all files to be compiled are +located in or below this directory. Typically this is used to access +private header files containing implementation details only. + + + + +The compiler flags $(CFLAGS) are determined in two +steps. First the appropriate HAL package will provide a configuration +option defining the global flags. Typically this includes flags that +are needed for the target processor, for example +-mcpu=arm9, various flags related to warnings, +debugging and optimization, and flags such as +-finit-priority which are needed by &eCos; itself. +Users can modify the global flags option as required. In addition it +is possible for existing flags to be removed from and new flags to be +added to the current set on a per-package basis, again by means of +user-modifiable configuration options. More details are given below. + + +Component writers can assume that the build system will perform full +header file dependency analysis, including dependencies on +configuration headers, but the exact means by which this happens is +implementation-defined. Typical application developers are unlikely to +modify exported or private header files, but configuration headers are +likely to change as the configuration is changed to better meet the +needs of the application. Full header file dependency analysis also +makes things easier for the component writers themselves. + + +The current directory used during a compilation is an implementation +detail of the build system. However it can be assumed that each +package will have its own directory somewhere in the build tree, to +prevent file name clashes, that this will be the current directory, +and that intermediate object files will end up here. + + + + + + + + +Generating the Libraries + + +Once all the &compile; and &make-object; properties have been +processed and the required object files have been built or rebuilt, +these can be collected together in one or more libraries. The archiver +will be the ar command +corresponding to the current architecture, for example powerpc-eabi-ar. By default al of the +object files will end up in a single library +libtarget.a. This can be changed on a per-package +basis using the &library property +in the body of the corresponding &cdl-package; command, for example: + + +cdl_package <SOME_PACKAGE> { + … + library libSomePackage.a +} + + + +However using different libraries for each package should be avoided. +It makes things more difficult for application developers since they +now have to link the application code with more libraries, and +possibly even change this set of libraries when packages are added to +or removed from the configuration. The use of a single library +libtarget.a avoids any complications. + + +It is also possible to change the target library for individual files, +using a -library option with the corresponding +&compile; or &make-object; property. For example: + + + compile -library=libSomePackage.a hello.c + make_object -library=libSomePackage.a { + … + } + + +Again this should be avoided because it makes application development +more difficult. There is one special library which can be used freely, +libextras.a, which is used to generate the +extras.o file as described below. + + +The order in which object files end up in a library is not defined. +Typically each library will be created directly in the install tree, +since there is little point in generating a file in the build tree and +then immediately copying it to the install tree. + + + + + + + + +The <filename>extras.o</filename> file + + +Package sources files normally get compiled and then added to a +library, by default libtarget.a, which is then +linked with the application code. Because of the usual rules for +linking with libraries, augmented by the use of link-time garbage +collection, this means that code will only end up in the final +executable if there is a direct or indirect reference to it in the +application. Usually this is the desired behaviour: if the application +does not make any use of say kernel message boxes, directly or +indirectly, then that code should not end up in the final executable +taking up valuable memory space. + + +In a few cases it is desirable for package code to end up in the final +executable even if there are no direct or indirect references. For +example, device driver functions are often not called directly. +Instead the application will access the device via the string +"/dev/xyzzy" and call the device functions +indirectly. This will be impossible if the functions have been +removed at link-time. + + +Another example involves static C++ objects. It is possible to have a +static C++ object, preferably with a suitable constructor priority, +where all of the interesting work happens as a side effect of running +the constructor. For example a package might include a monitoring +thread or a garbage collection thread created from inside such a +constructor. Without a reference by the application to the static +object the latter will never get linked in, and the package will not +function as expected. + + +A third example would be copyright messages. A package vendor may want +to insist that all products shipped using that package include a +particular message in memory, even though many users of that package +will object to such a restriction. + + +To meet requirements such as these the build system provides support +for a file extras.o, which always gets linked +with the application code via the linker script. Because it is an +object file rather than a library everything in the file will be +linked in. The extras.o file is generated at the +end of a build from a library libextras.a, so +packages can put functions and variables in suitable source files and +add them to that library explicitly: + + + compile -library=libextras.a xyzzy.c + compile xyzzy_support.c + + +In this example xyzzy.o will end up in +libextras.a, and hence in +extras.o and in the final executable. +xyzzy_support.o will end up in +libtarget.a as usual, and is subject to linker +garbage collection. + + + + + + + + +Compilers and Flags + + + +Some of the details of compiler selection and compiler flags described +below are subject to change in future revisions of the component +framework, although every reasonable attempt will be made to avoid +breaking backwards compatibility. + + + + +The build system needs to know what compiler to use, what compiler +flags should be used for different stages of the build and so on. Much +of this information will vary from target to target, although users +should be able to override this when appropriate. There may also be a +need for some packages to modify the compiler flags. All platform HAL +packages should define a number of options with well-known names, +along the following lines (any existing platform HAL package can be +consulted for a complete example): + + +cdl_component CYGBLD_GLOBAL_OPTIONS { + flavor none + parent CYGPKG_NONE + … + + cdl_option CYGBLD_GLOBAL_COMMAND_PREFIX { + flavor data + default_value { "arm-elf" } + … + } + cdl_option CYGBLD_GLOBAL_CFLAGS { + flavor data + default_value "-Wall -g -O2 …" + … + } + + cdl_option CYGBLD_GLOBAL_LDFLAGS { + flavor data + default_value "-g -nostdlib -Wl,--gc-sections …" + … + } +} + + +The CYGBLD_GLOBAL_OPTIONS component serves to +collect together all global build-related options. It has the flavor +none since disabling all of these options would +make it impossible to build anything and hence is not useful. It is +parented immediately below the root of the configuration hierarchy, +thus making sure that it is readily accessible in the graphical +configuration tool and, for command line users, in the +ecos.ecc save file. + + + +Currently the &parent; property lists a parent of +CYGPKG_NONE, rather than an empty string. This +could be unfortunate if there was ever a package with that name. The +issue will be addressed in a future release of the component +framework. + + + +The option CYGBLD_GLOBAL_COMMAND_PREFIX defines +which tools should be used for the current target. Typically this is +determined by the processor on the target hardware. In some cases a +given target board may be able to support several different +processors, in which case the &default-value; expression could select +a different toolchain depending on some other option that is used to +control which particular processor. +CYGBLD_GLOBAL_COMMAND_PREFIX is modifiable rather +than calculated, so users can override this when necessary. + + +Given a command prefix such as arm-elf, all C +source files will be compiled with arm-elf-gcc, all +C++ sources will be built using arm-elf-g++, +and arm-elf-ar will be used to generate the +library. This is in accordance with the usual naming conventions for +GNU cross-compilers and similar tools. For the purposes of custom +build steps, tokens such as $(CC) will be set to +arm-elf-gcc. + + +The next option, CYGBLD_GLOBAL_CFLAGS, is used to +provide the initial value of $(CFLAGS). Some +compiler flags such as -Wall and +-g are likely to be used on all targets. Other +flags such as -mcpu=arm7tdmi will be +target-specific. Again this is a modifiable option, so the user can +switch from say -O2 to -Os if +desired. The option CYGBLD_GLOBAL_LDFLAGS serves +the same purpose for $(LDFLAGS) and linking. It is +used primarily when building test cases or possibly for some custom +build steps, since building eCos itself generally involves building +one or more libraries rather than executables. + + +Some packages may wish to add certain flags to the global set, or +possibly remove some flags. This can be achieved by having +appropriately named options in the package, for example: + + +cdl_component CYGPKG_KERNEL_OPTIONS { + display "Kernel build options" + flavor none + … + + cdl_option CYGPKG_KERNEL_CFLAGS_ADD { + display "Additional compiler flags" + flavor data + default_value { "" } + … + } + + cdl_option CYGPKG_KERNEL_CFLAGS_REMOVE { + display "Suppressed compiler flags" + flavor data + default_value { "" } + … + } + + cdl_option CYGPKG_KERNEL_LDFLAGS_ADD { + display "Additional linker flags" + flavor data + default_value { "" } + … + } + + cdl_option CYGPKG_KERNEL_LDFLAGS_REMOVE { + display "Suppressed linker flags" + flavor data + default_value { "" } + … + } +} + + +In this example the kernel does not modify the global compiler flags +by default, but it is possible for the users to modify the options if +desired. The value of $(CFLAGS) that is used for +the compilations and custom build steps in a given package is +determined as follows: + + + + +Start with the global settings from +CYGBLD_GLOBAL_CFLAGS, for example +-g -O2. + + + + +Remove any flags specified in the per-package +CFLAGS_REMOVE option, if any. For example +if -O2 should be removed for this package then +$(CFLAGS) would now have a value of just +-g. + + + + +Then concatenate the flags specified by the per-package +CFLAGS_ADD option, if any. For example if +-Os should be added for the current package then +the final value of $(CFLAGS) will be +-g -Os. + + + + +$(LDFLAGS) is determined in much the same way. + + + + +The way compiler flags are handled at present has numerous limitations +that need to be addressed in a future release, although it should +suffice for nearly all cases. For the time being custom build steps +and in particular the &make-object; property can be used to work +around the limitations. + + +Amongst the issues, there is a specific problem with package +encapsulation. For example the math library imposes some stringent +requirements on the compiler in order to guarantee exact IEEE +behavior, and may need special flags on a per-architecture basis. One +way of handling this is to have +CYGPKG_LIBM_CFLAGS_ADD and +CYGPKG_LIBM_CFLAGS_REMOVE &default-value; +expressions which depend on the target architecture, but such +expressions may have to updated for each new architecture. An +alternative approach would allow the architectural HAL package to +modify the &default-value; expressions for the math library, but this +breaks encapsulation. A third approach would allow some architectural +HAL packages to define one or more special options with well-known +names, and the math library could check if these options were defined +and adjust the default values appropriately. Other packages with +floating point requirements could do the same. This approach also has +scalability issues, in particular how many such categories of options +would be needed? It is not yet clear how best to resolve such issues. + + + + + +When generating a build tree it would be desirable for the component +framework to output details of the tools and compiler flags in a +format that can be re-used for application builds, for example a +makefile fragment. This would make it easier for application +developers to use the same set of flags as were used for building eCos +itself, thus avoiding some potential problems with incompatible +compiler flags. + + + + + + + + + +Custom Build Steps + + + +Some of the details of custom build steps as described below are +subject to change in future revisions of the component framework, +although every reasonable attempt will be made to avoid breaking +backwards compatibility. + + + + +For most packages simply listing one or more source files in a +&compile; property is sufficient. These files will get built using the +appropriate compiler and compiler flags and added to a library, which +then gets linked with application code. A package that can be built in +this way is likely to be more portable to different targets and build +environments, since it avoids build-time dependencies. However some +packages have special needs, and the component framework supports +custom build steps to allow for these needs. There are two properties +related to this, &make; and &make-object;, and both take the following +form: + + + make { + <target_filepath> : <dependency_filepath> … + <command> + ... + } + + +Although this may look like makefile syntax, and although some build +environments will indeed involve generating makefiles and running +make, this is not +guaranteed. It is possible for the component framework to be +integrated with some other build system, and custom build steps should +be written with that possibility in mind. Each custom build step +involves a target, some number of dependency files, and some number of +commands. If the target is not up to date with respect to one or more +of the dependencies then the commands need to be executed. + + + + + + +Only one target can be specified. For a &make-object; property this +target must be an object file. For a &make; property it can be any +file. In both cases it must refer to a physical file, the use of +phony targets is not supported. The target should not be an absolute +path name. If the generated file needs to end up in the install tree +then this can be achieved using a <PREFIX> +token, for example: + + + make { + <PREFIX>/lib/mytarget : … + ... + } + + +When the build tree is generated and the custom build step is added to +the makefile (or whatever build system is used) +<PREFIX> will be replaced with the absolute +path to the install tree. + + + + + +All the dependencies must also refer to physical files, not to phony +targets. These files may be in the source tree. The +<PACKAGE> token can be used to indicate this: +when the build tree is generated this token will be replaced with the +absolute path to the package's root directory in the component +repository, for example: + + + make_object { + xyzzy.o : <PACKAGE>/src/xyzzy.c + … + + +If the component repository was installed in /usr/local/ecos and this custom build +step existed in version 1_5 of the kernel, +<PACKAGE> would be replaced with +/usr/local/ecos/packages/kernel/v1_5. + + +Alternatively the dependencies may refer to files that are generated +during the build. These may be object files resulting from &compile; +properties or other &make-object; properties, or they may be other +files resulting from a &make; property, for example: + + + compile plugh.c + make_object { + xyzzy.o : plugh.o + … + } + + + + +No other token or makefile variables may be used in the target or +dependency file names. Also conditionals such as +ifneq and similar makefile functionality must not +be used. + + + + + +Similarly the list of commands must not use any makefile conditionals +or similar functionality. A number of tokens can be used to provide +access to target-specific or environmental data. Note that these +tokens look like makefile variables, unlike the +<PREFIX> and +<PACKAGE> tokens mentioned earlier: + + + + + + + Token + Purpose + Example value + + + + + $(AR) + the GNU archiver + mips-tx39-elf-ar + + + $(CC) + the GNU compiler + sh-elf-gcc + + + $(CFLAGS) + compiler flags + -O2 -Wall + + + $(COMMAND_PREFIX) + the triplet prefix + mn10300-elf- + + + $(INCLUDE_PATH> + header file search path + -I. -Isrc/misc + + + $(LDFLAGS) + linker flags + -nostdlib -Wl,-static + + + $(OBJCOPY) + the objcopy utility + arm-elf-objcopy + + + $(PREFIX) + location of the install tree + /home/fred/ecos-install + + + $(REPOSITORY) + location of the component repository + /home/fred/ecos/packages + + + + + + +In addition commands in a custom build step may refer to the target +and the dependencies using $@, +$<, $^ and +$*, all of which behave as per GNU make syntax. The +commands will execute in a suitable directory in the build tree. + + + + + +The current directory used during a custom build step is an +implementation detail of the build system. However it can be assumed +that each package will have its own directory somewhere in the build +tree, to prevent file name clashes, and that this will be the current +directory. In addition any object files generated as a result of +&compile properties will be located here as well, which is useful for +custom build steps that depend on a .o file +previously generated. + + +Any temporary files created by a custom build step should be generated +in the build tree (in or under the current directory). Such files +should be given a .tmp file extension to ensure +that they are deleted during a make clean or +equivalent operation. + + +If a package contains multiple custom build steps with the same +priority, it is possible that these build steps will be run +concurrently. Therefore these custom build steps must not accidentally +use the same file names for intermediate files. + + + + + +Care has to be taken to make sure that the commands in a custom build +step will run on all host platforms, including Windows NT as well as +Linux and other Unix systems. For example, all file paths should use +forward slashes as the directory separator. It can be assumed that +Windows users will have a full set of CygWin tools installed and +available on the path. The GNU coding +standards provide some useful guidelines for writing portable +build rules. + + + + + +A custom build step must not make any assumptions concerning the +version of another package. This enforces package encapsulation, +preventing one package from accessing the internals of another. + + + + + +No assumptions should be made about the target platform, unless the +package is inherently specific to that platform. Even then it is +better to use the various tokens whenever possible, rather than +hard-coding in details such as the compiler. For example, given a +custom build step such as: + + + arm-elf-gcc -c -mcpu=arm7di -o $@ $< + + +Even if this build step will only be invoked on ARM targets, it could +cause problems. For example the toolchain may have been installed +using a prefix other than arm-elf. Also, if the +user changes the compiler flags then this would not be reflected in +the build step. The correct way to write this rule would be: + + + $(CC) -c $(CFLAGS) -o $@ $< + + +Some commands such as the compiler, the archiver, and objcopy are +required sufficiently often to warrant their own tokens, for example +$(CC) and $(OBJCOPY). Other +target-specific commands are needed only rarely and the +$(COMMAND_PREFIX) token can be used to construct +the appropriate command name, for example: + + + + $(COMMAND_PREFIX)size $< > $@ + + + + + +Custom build steps should not be used to build host-side executables, +even if those executables are needed to build parts of the target side +code. Support for building host-side executables will be added in a +future version of the component framework, although it will not +necessarily involve these custom build steps. + + + + + + +By default custom build steps defined in a &make-object; property +have a priority of 100, which means that they will be executed +in the same phase as compilations resulting from a &compile; property. +It is possible to change the priority using a property option, for +example: + + + make_object -priority 50 { + … + } + + +Specifying a priority smaller than a 100 means that the custom build +step happens before the normal compilations. Priorities between 100 +and 200 happen after normal compilations but before the libraries are +archived together. &make-object; properties should not specify a +priority of 200 or later. + + +Custom build steps defined in a &make; property have a default +priority of 300, and so they will happen after the libraries have been +built. Again this can be changed using a -priority +property option. + + + + + + + + +Startup Code + + +Linking an application requires the application code, a linker script, +the eCos library or libraries, the extras.o file, +and some startup code. Depending on the target hardware and how the +application gets booted, this startup code may do little more than +branching to main(), or it may have to perform a +considerable amount of hardware initialization. The startup code +generally lives in a file vectors.o which is +created by a custom build step in a HAL package. As far as application +developers are concered the existence of this file is largely +transparent, since the linker script ensures that the file is part of +the final executable. + + +This startup code is not generally of interest to component writers, +only to HAL developers who are referred to one of the existing HAL +packages for specific details. Other packages are not expected to +modify the startup in any way. If a package needs some work performed +early on during system initialization, before the application's main +entry point gets invoked, this can be achieved using a static object +with a suitable constructor priority. + + + + +It is possible that the extras.o support, in +conjunction with appropriate linker script directives, could be used +to eliminate the need for a special startup file. The details are not +yet clear. + + + + + + + + + +The Linker Script + + + +This section is not finished, and the details are subject to change in +a future release. Arguably linker script issues should be documented +in the HAL documentation rather than in this guide. + + + + +Generating the linker script is the responsibility of the various HAL +packages that are applicable to a given target. Developers of +components other than HAL packages need not be concerned about what is +involved. Developers of new HAL packages should use an existing HAL as +a template. + + + + +It may be desirable for some packages to have some control over the +linker script, for example to add extra alignment details for a +particular section. This can be risky because it can result in subtle +portability problems, and the current component framework has no +support for any such operations. The issue may be addressed in a +future release. + + + + + + + + + + + + + +Building Test Cases + + + +The support in the current implementation of the component framework +for building and running test cases is limited, and should be enhanced +considerably in a future version. Compatibility with the existing +mechanisms described below will be maintained if possible, but this +cannot be guaranteed. + + + + +Whenever possible packages should be shipped with one or more test +cases. This allows users to check that all packages function correctly +in their particular configuration and on their target, which may be +custom hardware unavailable to the package developer. The component +framework needs to provide a way of building such test cases. For +example, if a makefile system is used then there could be a +make tests target to build the test cases, or +possibly a make check target to build and run +the test cases and process all the results. Unfortunately there are +various complications. + + +Not every test case will be applicable to every configuration. For +example if the user has disabled the C library's +CYGPKG_LIBC_STDIO component then there is no point +in building or running any of the test cases for that component. This +implies that test cases need to be associated with configuration +options somehow. It is possible for the test case to use one or more +#ifdef statements to check whether or not it is +applicable in the current configuration, and compile to a null program +when not applicable. This is inefficient because the test case will +still get built and possibly run, even though it will not provide any +useful information. + + +Many packages involve direct interaction with hardware, for example a +serial line or an ethernet interface. In such cases it is only +worthwhile building and running the test if there is suitable software +running at the other end of the serial line or listening on the same +ethernet segment, and that software would typically have to run on the +host. Of course the serial line in question may be hooked up to a +different piece of hardware which the application needs to talk to, so +disconnecting it and then hooking it up to the host for running some +tests may be undesirable. The decision as to whether or not to build +the test depends not just on the eCos configuration but also on the +hardware setup and the availability of suitable host software. + + +There are different kinds of tests, and it is not always desirable to +run all of them. For example a package may contain a number of stress +tests intended to run for long periods of time, possibly days or +longer. Such tests should certainly be distinguished somehow from +ordinary test cases so that users will not run them accidentally and +wonder how long they should wait for a pass message +before giving up. Stress tests may also have dependencies on the +hardware configuration and on host software, for example a network +stress test may require lots of ethernet packets. + + +In the current implementation of the component framework these issues +are not yet addressed. Instead there is only very limited support for +building test cases. Any package can define a calculated configuration +option of the form +CYGPKG_<package-name>_TESTS, whose value is a +list of test cases. The &calculated; property can involve an +expression so it is possible to adapt to a small number of +configuration options, but this quickly becomes unwieldy. A typical +example would be: + + + cdl_option CYGPKG_UITRON_TESTS { + display "uITRON tests" + flavor data + no_define + calculated { "tests/test1 tests/test2 tests/test3 \ + tests/test4 tests/test5 tests/test6 tests/test7 \ + tests/test8 tests/test9 tests/testcxx tests/testcx2 \ + tests/testcx3 tests/testcx4 tests/testcx5 \ + tests/testcx6 tests/testcx7 tests/testcx8 \ + tests/testcx9 tests/testintr" } + description " +This option specifies the set of tests for the uITRON compatibility layer." + } + + + +This implies that there is a file tests/test1.c +or tests/test1.cxx in the package's directory. +The commands that will be used to build the test case will take the +form: + + + $(CC) -c $(INCLUDE_PATH) $(CFLAGS) -o <build path>/test1.o \ + <source path>/tests/test1.c + $(CC) $(LDFLAGS) -o <install path>/tests/test1 <build_path>/test1.o + + +The variables $(CC) and so on are determined in the +same way as for custom build steps. The various paths and the current +directory will depend on the exact build system being used, and are +subject to change. As usual the sources in the component repository +are treated as a read-only resources, intermediate files live in the +build tree, and the desired executables should end up in the install +tree. + + +Each test source file must be self-contained. It is not possible at +present to build a little per-package library that can be used by the +test cases, or to link together several object files to produce a +single test executable. In some cases it may be possible to +#include source code from a shared file in order to +avoid unnecessary code replication. There is no support for +manipulating compiler or linker flags for individual test cases: the +flags that will be used for all files are $(CFLAGS) +and $(LDFLAGS), as per custom build steps. Note +that it is possible for a package to define options of the form +CYGPKG_<PACKAGE-NAME>_LDFLAGS_ADD and +CYGPKG_<PACKAGE-NAME>_LDFLAGS_REMOVE. These +will affect test cases, but in the absence of custom build steps they +will have no other effect on the build. + + + + + + + \ No newline at end of file diff --git a/host/libcdl/doc/concepts.sgml b/host/libcdl/doc/concepts.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/concepts.sgml @@ -0,0 +1,820 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Overview + + + + +&eCos; was designed from the very beginning as a configurable +component architecture. The core &eCos; system consists of a number of +different components such as the kernel, the C library, an +infrastructure package. Each of these provides a large number of +configuration options, allowing application developers to build a +system that matches the requirements of their particular application. +To manage the potential complexity of multiple components and lots of +configuration options, &eCos; comes with a component framework: a +collection of tools specifically designed to support configuring +multiple components. Furthermore this component framework is +extensible, allowing additional components to be added to the system +at any time. + + + + + + +Terminology + +The &eCos; component architecture involves a number of key concepts. + + + + + +Component Framework + + +The phrase component framework is used to describe +the collection of tools that allow users to configure a system and +administer a component repository. This includes the ecosconfig command line tool, the +graphical configuration tool, and the package administration tool. +Both the command line and graphical tools are based on a single +underlying library, the &CDL; library. + + + + + + + + +Configuration Option + +The option is the basic unit of configurability. Typically each option +corresponds to a single choice that a user can make. For example there +is an option to control whether or not assertions are enabled, and the +kernel provides an option corresponding to the number of scheduling +priority levels in the system. Options can control very small amounts +of code such as whether or not the C library's +strtok gets inlined. They can also control quite +large amounts of code, for example whether or not the +printf supports floating point conversions. + + +Many options are straightforward, and the user only gets to choose +whether the option is enabled or disabled. Some options are more +complicated, for example the number of scheduling priority levels is a +number that should be within a certain range. Options should always +start off with a sensible default setting, so that it is not necessary +for users to make hundreds of decisions before any work can start on +developing the application. Once the application is running the +various configuration options can be used to tune the system for the +specific needs of the application. + + +The component framework allows for options that are not directly +user-modifiable. Consider the case of processor endianness: some +processors are always big-endian or always little-endian, while with +other processors there is a choice. Depending on the user's choice of +target hardware, endianness may or may not be user-modifiable. + + + + + + + +Component + +A component is a unit of functionality such as a particular kernel +scheduler or a device driver for a specific device. A component is +also a configuration option in that users may want to enable +or disable all the functionality in a component. For example, if a +particular device on the target hardware is not going to be used by +the application, directly or indirectly, then there is no point in +having a device driver for it. Furthermore disabling the device driver +should reduce the memory requirements for both code and data. + + +Components may contain further configuration options. In the case of a +device driver, there may be options to control the exact behavior of +that driver. These will of course be irrelevant if the driver as a +whole is disabled. More generally options and components live in a +hierarchy, where any component can contain options specific to that +component and further sub-components. It is possible to view the +entire &eCos; kernel as one big component, containing sub-components +for scheduling, exception handling, synchronization primitives, and so +on. The synchronization primitives component can contain further +sub-components for mutexes, semaphores, condition variables, event +flags, and so on. The mutex component can contain configuration +options for issues like priority inversion support. + + + + + + + +Package + +A package is a special type of component. Specifically, a package is +the unit of distribution of components. It is possible to create a +distribution file for a package containing all of the source code, +header files, documentation, and other relevant files. This +distribution file can then be installed using the appropriate tool. +Afterwards it is possible to uninstall that package, or to install a +later version. The core &eCos; distribution comes with a number of +packages such as the kernel and the infrastructure. Other packages +such as network stacks can come from various different sources and can +be installed alongside the core distribution. + + +Packages can be enabled or disabled, but the user experience is a +little bit different. Generally it makes no sense for the tools to +load the details of every single package that has been installed. For +example, if the target hardware uses an ARM processor then there is no +point in loading the HAL packages for other architectures and +displaying choices to the user which are not relevant. Therefore +enabling a package means loading its configuration data into the +appropriate tool, and disabling a package is an unload operation. In +addition, packages are not just enabled or disabled: it is also +possible to select the particular version of a package that should be +used. + + + + + + + +Configuration + +A configuration is a collection of user choices. The various +tools that make up the component framework deal with entire +configurations. Users can create a new configuration, output a +savefile (by default ecos.ecc), manipulate a +configuration, and use a configuration to generate a build tree prior +to building &eCos; and any other packages that have been selected. +A configuration includes details such as which packages have been +selected, in addition to finer-grained information such as which +options in those packages have been enabled or disabled by the user. + + + + + + + +Target + +The target is the specific piece of hardware on which the application +is expected to run. This may be an off-the-shelf evaluation board, a +piece of custom hardware intended for a specific application, or it +could be something like a simulator. One of the steps when creating a +new configuration is need to specify the target. The component +framework will map this on to a set of packages that are used to +populate the configuration, typically HAL and device driver packages, +and in addition it may cause certain options to be changed from their +default settings to something more appropriate for the +specified target. + + + + + + + +Template + +A template is a partial configuration, aimed at providing users with +an appropriate starting point. &eCos; is shipped with a small number +of templates, which correspond closely to common ways of using the +system. There is a minimal template which provides very little +functionality, just enough to bootstrap the hardware and then jump +directly to application code. The default template adds additional +functionality, for example it causes the kernel and C library packages +to be loaded as well. The uitron template adds further functionality +in the form of a &uITRON; compatibility layer. Creating a new +configuration typically involves specifying a template as well as a +target, resulting in a configuration that can be built and linked with +the application code and that will run on the actual hardware. It is +then possible to fine-tune configuration options to produce something +that better matches the specific requirements of the application. + + + + + + + +Properties + +The component framework needs a certain amount of information about +each option. For example it needs to know what the legal values are, +what the default should be, where to find the on-line documentation if +the user needs to consult that in order to make a decision, and so on. +These are all properties of the option. Every option (including +components and packages) consists of a name and a set of properties. + + + + + + + +Consequences + +Choices must have consequences. For an &eCos; configuration the main +end product is a library that can be linked with application code, so +the consequences of a user choice must affect the build process. This +happens in two main ways. First, options can affect which files get +built and end up in the library. Second, details of the current option +settings get written into various configuration header files using C +preprocessor #define directives, and package source +code can #include these configuration headers and +adapt accordingly. This allows options to affect a package at a very +fine grain, at the level of individual lines in a source file if +desired. There may be other consequences as well, for example there +are options to control the compiler flags that get used during the +build process. + + + + + + + +Constraints + +Configuration choices are not independent. The C library can provide +thread-safe implementations of functions like +rand, but only if the kernel provides support for +per-thread data. This is a constraint: the C library option has a +requirement on the kernel. A typical configuration involves a +considerable number of constraints, of varying complexity: many +constraints are straightforward, option A requires +option B, or option C precludes +option D. Other constraints can be more +complicated, for example option E may require the +presence of a kernel scheduler but does not care whether it is the +bitmap scheduler, the mlqueue scheduler, or something else. + + +Another type of constraint involves the values that can be used for +certain options. For example there is a kernel option related to the +number of scheduling levels, and there is a legal values constraint on +this option: specifying zero or a negative number for the number of +scheduling levels makes no sense. + + + + + + + +Conflicts + +As the user manipulates options it is possible to end up with an +invalid configuration, where one or more constraints are not +satisfied. For example if kernel per-thread data is disabled but the C +library's thread-safety options are left enabled then there are +unsatisfied constraints, also known as conflicts. Such conflicts will +be reported by the configuration tools. The presence of conflicts does +not prevent users from attempting to build &eCos;, but the +consequences are undefined: there may be compile-time failures, there +may be link-time failures, the application may completely fail to run, +or the application may run most of the time but once in a while there +will be a strange failure… Typically users will want to resolve +all conflicts before continuing. + + +To make things easier for the user, the configuration tools contain an +inference engine. This can examine a conflict in a particular +configuration and try to figure out some way of resolving the +conflict. Depending on the particular tool being used, the inference +engine may get invoked automatically at certain times or the user may +need to invoke it explicitly. Also depending on the tool, the +inference engine may apply any solutions it finds automatically or it +may request user confirmation. + + + + + + + +CDL + +The configuration tools require information about the various options +provided by each package, their consequences and constraints, and +other properties such as the location of on-line documentation. This +information has to be provided in the form of &CDL; scripts. CDL +is short for Component Definition Language, and is specifically +designed as a way of describing configuration options. + + +A typical package contains the following: + + + +Some number of source files which will end up in a library. The +application code will be linked with this library to produce an +executable. Some source files may serve other purposes, for example to +provide a linker script. + + +Exported header files which define the interface provided by the +package. + + +On-line documentation, for example reference pages for each exported +function. + + +Some number of test cases, shipped in source format, allowing users to +check that the package is working as expected on their particular +hardware and in their specific configuration. + + +One or more &CDL; scripts describing the package to the configuration +system. + + + +Not all packages need to contain all of these. For example some +packages such as device drivers may not provide a new interface, +instead they just provide another implementation of an existing +interface. However all packages must contain a &CDL; script that +describes the package to the configuration tools. + + + + + + + +Component Repository + +All &eCos; installations include a component repository. This is a +directory structure where all the packages get installed. The +component framework comes with an administration tool that allows new +packages or new versions of a package to be installed, old packages to +be removed, and so on. The component repository includes a simple +database, maintained by the administration tool, which contains +details of the various packages. + + +Generally application developers do not need to modify anything inside +the component repository, except by means of the administration tool. +Instead their work involves separate build and install trees. This +allows the component repository to be treated as a read-only resource +that can be shared by multiple projects and multiple users. Component +writers modifying one of the packages do need to manipulate files in +the component repository. + + + + + + + + + + + +Why Configurability? + +The &eCos; component framework places a great deal of emphasis on +configurability. The fundamental goal is to allow large parts of +embedded applications to be constructed from re-usable software +components, which does not a priori require that those components be +highly configurable. However embedded application development often +involves some serious constraints. + + +Many embedded applications have to work with very little memory, to +keep down manufacturing costs. The final application image that will +get blown into EPROM's or used to manufacture ROMs should contain only +the code that is absolutely necessary for the application to work, and +nothing else. If a few tens of kilobytes are added unnecessarily to a +typical desktop application then this is regrettable, but is quite +likely to go unnoticed. If an embedded application does not fit on the +target hardware then the problem is much more serious. The component +framework must allow users to configure the components so that any +unnecessary functionality gets removed. + + +Many embedded applications need deterministic behavior so that they +can meet real-time requirements. Such deterministic behavior can +often be provided, but at a cost in terms of code size, slower +algorithms, and so on. Other applications have no such real-time +requirements, or only for a small part of the overall system, and the +bulk of the system should not suffer any penalties. Again the +component framework must allow the users control over the timing +behavior of components. + + +Embedded systems tend to be difficult to debug. Even when it is +possible to get information out of the target hardware by means other +than flashing an LED, the more interesting debugging problems are +likely to be timing-related and hence very hard to reproduce and track +down. The re-usable components can provide debugging assistance in +various ways. They can provide functionality that can be exploited by +source level debuggers such as gdb, for example per-thread debugging +information. They can also contain various assertions so that problems +can be detected early on, tracing mechanisms to figure out what +happened before the assertion failure, and so on. Of course all of +these involve overheads, especially code size, and affect the timing. +Allowing users to control which debugging features are enabled for any +given application build is very desirable. + + +However, although it is desirable for re-usable components to provide +appropriate configuration options this is not required. It is possible +to produce a package which does not provide a single configuration +option — although the user still gets to choose +whether or not to use the package. In such cases it is still necessary +to provide a minimal CDL script, but its main purpose would be to +integrate the package with the component framework's build system. + + + + + + + +Approaches to Configurability + + +The purpose of configurability is to control the behavior of +components. A scheduler component may or may not support time slicing; +it may or may not support multiple priorities; it may or may not +perform error checking on arguments passed to the scheduler routines. +In the context of a desktop application a button widget may contain +some text or it may contain a picture; the text may be displayed in a +variety of fonts; the foreground and background color may vary. When +an application uses a component there must be some way of specifying +the desired behavior. The component writer has no way of knowing in +advance exactly how a particular component will end up being used. + + +One way to control the behavior is at run time. The application +creates an instance of a button object, and then instructs this object +to display either text or a picture. No special effort by the +application developer is required, since a button can always support +all desired behavior. There is of course a major disadvantage in +terms of the size of the final application image: the code that gets +linked with the application has to provide support for all possible +behavior, even if the application does not require it. + + +Another approach is to control the behavior at link-time, typically +by using inheritance in an object-oriented language. The button +library provides an abstract base class Button +and derived classes TextButton and +PictureButton. If an application only uses text +buttons then it will only create objects of type +TextButton, and the code for the +PictureButton class does not get used. In +many cases this approach works rather well and reduces the final image +size, but there are limitations. The main one is that you can only +have so many derived classes before the system gets unmanageable: a +derived class +TextButtonUsingABorderWidthOfOnePlusAWhiteBackgroundAndBlackForegroundAndATwelvePointTimesFontAndNoErrorCheckingOrAssertions +is not particularly sensible as far as most application developers are +concerned. + + +The &eCos; component framework allows the behavior of components to +be controlled at an even earlier time: when the component source code +gets compiled and turned into a library. The button component could +provide options, for example an option that only text buttons need to +be supported. The component gets built and becomes part of a library +intended specifically for the application, and the library will +contain only the code that is required by this application and nothing +else. A different application with different requirements would need +its own version of the library, configured separately. + + +In theory compile-time configurability should give the best possible +results in terms of code size, because it allows code to be controlled +at the individual statement level rather than at the function or +object level. Consider an example more closely related to embedded +systems, a package to support multi-threading. A standard routine +within such a package allows applications to kill threads +asynchronously: the POSIX routine for this is +pthread_cancel; the equivalent routine in &uITRON; +is ter_tsk. These routines themselves tend to +involve a significant amount of code, but that is not the real +problem: other parts of the system require extra code and data for the +kill routine to be able to function correctly. For example if a thread +is blocked while waiting on a mutex and is killed off by another +thread then the kill operation may have to do two things: remove the +thread from the mutex's queue of waiting threads; and undo the +effects, if any, of priority inheritance. The implementation requires +extra fields in the thread data structure so that the kill routine +knows about the thread's current state, and extra code in the mutex +routines to fill in and clear these extra fields correctly. + + +Most embedded applications do not require the ability to kill off a +thread asynchronously, and hence the kill routine will not get linked +into the final application image. Without compile-time configurability +this would still mean that the mutex code and similar parts of the +system contain code and data that serve no useful purpose in this +application. The &eCos; approach allows the user to select that the +thread kill functionality is not required, and all the components can +adapt to this at compile-time. For example the code in the mutex lock +routine contains statements to support the killing of threads, but +these statements will only get compiled in if that functionality is +required. The overall result is that the final application image +contains only the code and data that is really needed for the +application to work, and nothing else. + + +Of course there are complications. To return to the button example, +the application code might only use text buttons directly, but it +might also use some higher-level widget such as a file selector and +this file selector might require buttons with pictures. Therefore the +button code must still be compiled to support pictures as well as +text. The configuration tools must be aware of the dependencies +between components and ensure that the internal constraints are met, +as well as the external requirements of the application code. An area +of particular concern is conflicting requirements: a button component +might be written in such a way that it can only support either text +buttons or picture buttons, but not both in one application; this +would represent a weakness in the component itself rather than in the +component framework as a whole. + + +Compile-time configurability is not intended to replace the other +approaches but rather to complement them. There will be times when +run-time selection of behavior is desirable: for example an +application may need to be able to change the baud rate of a serial +line, and the system must then provide a way of doing this at +run-time. There will also be times when link-time selection is +desirable: for example a C library might provide two different random +number routines rand and +lrand48; these do not affect other code so there +is no good reason for the C library component not to provide both of +these, and allow the application code to use none, one, or both of +them as appropriate; any unused functions will just get eliminated at +link-time. Compile-time selection of behavior is another option, and +it can be the most powerful one of the three and the best suited to +embedded systems development. + + + + + + + + +Degrees of Configurability + + +Components can support configurability in varying degrees. It is not +necessary to have any configuration options at all, and the only user +choice is whether or not to load a particular package. Alternatively +it is possible to implement highly-configurable code. As an example +consider a typical facility that is provided by many real-time +kernels, mutex locks. The possible configuration options include: + + + + + + +If no part of the application and no other component requires mutexes +then there is no point in having the mutex code compiled into a +library at all. This saves having to compile the code. In addition +there will never be any need for the user to configure the detailed +behavior of mutexes. Therefore the presence of mutexes is a +configuration option in itself. + + + + + +Even if the application does make use of mutexes directly or +indirectly, this does not mean that all mutex functions have to be +included. The minimum functionality consists of lock and unlock +functions. However there are variants of the locking primitive such as +try-lock and try-with-timeout which may or may not be needed. + + +Generally it will be harmless to compile the try-lock function even if +it is not actually required, because the function will get eliminated +at link-time. Some users might take the view that the try-lock +function should never get compiled in unless it is actually needed, to +reduce compile-time and disk usage. Other users might argue that there +are very few valid uses for a try-lock function and it should not be +compiled by default to discourage incorrect uses. The presence of a +try-lock function is a possible configuration option, although it may +be sensible to default it to true. + + +The try-with-timeout variant is more complicated because it adds a +dependency: the mutex code will now rely on some other component to +provide a timer facility. To make things worse the presence of this +timer might impact other components, for example it may now be +necessary to guard against timer interrupts, and thus have an +insidious effect on code size. The presence of a lock-with-timeout +function is clearly a sensible configuration option, but the default +value is less obvious. If the option is enabled by default then the +final application image may end up with code that is not actually +essential. If the option is disabled by default then users will have +to enable the option somehow in order to use the function, implying +more effort on the part of the user. One possible approach is to +calculate the default value based on whether or not a timer component +is present anyway. + + + + + +The application may or may not require the ability to create and +destroy mutexes dynamically. For most embedded systems it is both less +error-prone and more efficient to create objects like mutexes +statically. Dynamic creation of mutexes can be implemented using a +pre-allocated pool of mutex objects, involving some extra code to +manipulate the pool and an additional configuration option to define +the size of the pool. Alternatively it can be implemented using a +general-purpose memory allocator, involving quite a lot of extra code +and configuration options. However this general-purpose memory +allocator may be present anyway to support the application itself or +some other component. The ability to create and destroy mutexes +dynamically is a configuration option, and there may not be a sensible +default that is appropriate for all applications. + + + + + +An important issue for mutex locks is the handling of priority +inversion, where a high priority thread is prevented from running +because it needs a lock owned by a lower priority thread. This is only +an issue if there is a scheduler with multiple priorities: some +systems may need multi-threading and hence synchronization primitives, +but a single priority level may suffice. If priority inversion is a +theoretical possibility then the application developer may still want +to ignore it because the application has been designed such that the +problem cannot arise in practice. Alternatively the developer may want +some sort of exception raised if priority inversion does occur, +because it should not happen but there may still be bugs in the code. +If priority inversion can occur legally then there are three main ways +of handling it: priority ceilings, priority inheritance, and ignoring +the problem. Priority ceilings require little code but extra effort on +the part of the application developer. Priority inheritance requires +more code but is automatic. Ignoring priority inversion may or may not +be acceptable, depending on the application and exactly when priority +inversion can occur. Some of these choices involve additional +configuration options, for example there are different ways of raising +an exception, and priority inheritance may or may not be applied +recursively. + + + + + +As a further complication some mutexes may be hidden inside a +component rather than being an explicit part of the application. For +example, if the C library is configured to provide a +malloc call then there may be an associated mutex +to make the function automatically thread-safe, with no need for +external locking. In such cases the memory allocation component of the +C library can impose a constraint on the kernel, requiring that +mutexes be provided. If the user attempts to disable mutexes anyway +then the configuration tools will report a conflict. + + + + + +The mutex code should contain some general debugging code such as +assertions and tracing. Usually such debug support will be enabled or +disabled at a coarse level such as the entire system or everything +inside the kernel, but sometimes it will be desirable to enable the +support more selectively. One reason would be memory requirements: the +target may not have enough memory to hold the system if all debugging +is enabled. Another reason is if most of the system is working but +there are a few problems still to resolved; enabling debugging in the +entire system might change the system's timing behavior too much, but +enabling some debug options selectively can still be useful. There +should be configuration options to allow specific types of debugging +to be enabled at a fine-grain, but with default settings inherited +from an enclosing component or from global settings. + + + + + +The mutex code may contain specialized code to interact +with a debugging tool running on the host. It should be +possible to enable or disable this debugging code, and there may +be additional configuration options controlling the detailed +behavior. + + + + + + +Altogether there may be something like ten to twenty configuration +options that are specific to the mutex code. There may be a similar +number of additional options related to assertions and other debug +facilities. All of the options should have sensible default values, +possibly fixed, possibly calculated depending on what is happening +elsewhere in the configuration. For example the default setting for +an assertion option should generally inherit from a kernel-wide +assertion control option, which in turn inherits from a global option. +This allows users to enable or disable assertions globally or at +a more fine-grained level, as desired. + + +Different components may be configurable to different degrees, ranging +from no options at all to the fine-grained configurability of the +above mutex example (or possibly even further). It is up to component +writers to decide what options should be provided and how best to +serve the needs of application developers who want to use that +component. + + + + + + + +Warnings + +Large parts of &eCos; were developed concurrently with the development +of the configuration technology, or in some cases before design work +on that technology was complete. As a consequence the various &eCos; +packages often make only limited use of the available functionality. +This situation is expected to change over time. It does mean that many +of the descriptions in this guide will not correspond exactly to how +the &eCos; packages work right now, but rather to how they could work. +Some of the more extreme discrepancies such as the location of on-line +documentation in the component repository will be mentioned in the +appropriate places in the guide. + + +A consequence of this is that developers of new components can look at +existing &CDL; scripts for examples, and discover discrepancies +between what is recommended in this guide and what actually happens at +present. In such cases this guide should be treated as authoritative. + + +It is also worth noting that the current component framework is not +finished. Various parts of this guide will refer to possible changes +and enhancements in future versions. Examining the source code of the +configuration tools may reveal hints about other likely developments, +and there are many more possible enhancements which only exist at a +conceptual level right now. + + + + + + + \ No newline at end of file diff --git a/host/libcdl/doc/language.sgml b/host/libcdl/doc/language.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/language.sgml @@ -0,0 +1,3561 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +The CDL Language + + + + +The &CDL; language is a key part of the &eCos; component framework. +All packages must come with at least one &CDL; script, to describe +that package to the framework. The information in that script includes +details of all the configuration options and how to build the package. +Implementing a new component or turning some existing code into an +&eCos; component always involves writing corresponding &CDL;. This +chapter provides a description of the &CDL; language. Detailed +information on specific parts of the language can be found in . + + + + + + +Language Overview + +A very simple &CDL; script would look like this: + + +cdl_package CYGPKG_ERROR { + display "Common error code support" + compile strerror.cxx + include_dir cyg/error + description " + This package contains the common list of error and + status codes. It is held centrally to allow + packages to interchange error codes and status + codes in a common way, rather than each package + having its own conventions for error/status + reporting. The error codes are modelled on the + POSIX style naming e.g. EINVAL etc. This package + also provides the standard strerror() function to + convert error codes to textual representation." +} + + +This describes a single package, the error code package, which does +not have any sub-components or configuration options. The package has +an internal name, CYGPKG_ERROR, which can be +referenced in other &CDL; scripts using e.g. +requires CYGPKG_ERROR. There will also be a +#define for this symbol in a configuration header +file. In addition to the package name, this script provides a number +of properties for the package as a whole. The &display; property +provides a short description. The &description; property involves a +rather longer one, for when users need a bit more information. The +&compile; and &include-dir; properties list the consequences of this +package at build-time. The package appears to lack any on-line +documentation. + + +Packages could be even simpler than this. If the package only provides +an interface and there are no files to be compiled then there is no +need for a &compile; property. Alternatively if there are no exported +header files, or if the exported header files should go to the +top-level of the install/include directory, then there is +no need for an &include-dir; property. Strictly speaking the +&description; and &display; properties are optional as well, although +application developers would not appreciate the resulting lack of +information about what the package is supposed to do. + + +However many packages tend to be a bit more complicated than the error +package, containing various sub-components and configuration options. +These are also defined in the &CDL; scripts and in much the same way +as the package. For example, the following excerpt comes from the +infrastructure package: + + +cdl_component CYGDBG_INFRA_DEBUG_TRACE_ASSERT_BUFFER { + display "Buffered tracing" + default_value 1 + active_if CYGDBG_USE_TRACING + description " + An output module which buffers output from tracing and + assertion events. The stored messages are output when an + assert fires, or CYG_TRACE_PRINT() (defined in + <cyg/infra/cyg_trac.h>) is called. Of course, there will + only be stored messages if tracing per se (CYGDBG_USE_TRACING) + is enabled above." + + cdl_option CYGDBG_INFRA_DEBUG_TRACE_BUFFER_SIZE { + display "Trace buffer size" + flavor data + default_value 32 + legal_values 5 to 65535 + description " + The size of the trace buffer. This counts the number of + trace records stored. When the buffer fills it either + wraps, stops recording, or generates output." + } + + … +} + + +Like a &cdl-package;, a &cdl-component; has a name and a body. The +body contains various properties for that component, and may also +contain sub-components or options. Similarly a &cdl-option; has a +name and a body of properties. This example lists a number of +new properties: &default-value;, &active-if;, &flavor; and +&legal-values;. The meaning of most of these should be fairly obvious. +The next sections describe the various &CDL; commands and properties. + + +There is one additional and very important point: &CDL; is not a +completely new language; instead it is implemented as an extension of +the existing &Tcl; scripting language. The syntax of a &CDL; script is +&Tcl; syntax, which is described below. In addition some of the more +advanced facilities of &CDL; involve embedded fragments of &Tcl; code, +for example there is a &define-proc; property which specifies some +code that needs to be executed when the component framework generates +the configuration header files. + + + + + + + + +CDL Commands + +There are four &CDL;-related commands which can occur at the top-level +of a &CDL; script: &cdl-package;, &cdl-component;, &cdl-option; and +&cdl-interface;. These correspond to the basic building blocks of the +language (CDL interfaces are described in ). All of these take the same basic form: + + +cdl_package <name> { + … +} + +cdl_component <name> { + … +} + +cdl_option <name> { + … +} + +cdl_interface <name> { + … +} + + +The command is followed by a name and by a body of properties, the +latter enclosed in braces. Packages and components can contain other +entities, so the &cdl-package; and &cdl-component; can also have +nested commands in their bodies. All names must be unique within a +given configuration. If say the C library package and a TCP/IP stack +both defined an option with the same name then it would not be +possible to load both of them into a single configuration. There is a +naming convention which should +make accidental name clashes very unlikely. + + +It is possible for two packages to use the same name if there are no +reasonable circumstances under which both packages could be loaded at +the same time. One example would be architectural HAL packages: a +given &eCos; configuration can be used on only one processor, so the +architectural HAL packages CYGPKG_HAL_ARM and +CYGPKG_HAL_I386 can re-use option names; in fact +in some cases they are expected to. + + +Each package has one top-level &CDL; script, which is specified in the +packages ecos.db database +entry. Typically the name of this top-level script is related to +the package, so the kernel package uses +kernel.cdl, but this is just a convention. The +first command in the top-level script should be &cdl-package;, and the +name used should be the same as in the ecos.db +database. There should be only one &cdl-package; command per package. + + +The various &CDL; entities live in a hierarchy. For example the kernel +package contains a scheduling component, a synchronization primitives +component, and a number of others. The synchronization component +contains various options such as whether or not mutex priority +inheritance is enabled. There is no upper bound on how far components +can be nested, but it is rarely necessary to go more than three or +four levels deeper than the package level. Since the naming convention +incorporates bits of the hierarchy, this has the added advantage of +keeping the names down to a more manageable size. + + +The hierarchy serves two purposes. It allows options to be controlled +en masse, so disabling a component automatically disables all the +options below it in the hierarchy. It also permits a much simpler +representation of the configuration in the graphical configuration +tool, facilitating navigation and modification. + + +By default a package is placed at the top-level of the hierarchy, but +it is possible to override this using a &parent; property. For example +an architectural HAL package such as CYGPKG_HAL_SH +typically re-parents itself below CYGPKG_HAL, and a +platform HAL package would then re-parent itself below the +architectural HAL. This makes it a little bit easier for users to +navigate around the hierarchy. Components, options and interfaces can +also be re-parented, but this is less common. + + +All components, options and interfaces that are defined directly in +the top-level script will be placed below the package in the hierarchy. +Alternatively they can be nested in the body of the &cdl-package; +command. The following two script fragments are equivalent: + + +cdl_package CYGPKG_LIBC { + … +} + +cdl_component CYGPKG_LIBC_STRING { + … +} + +cdl_option CYGPKG_LIBC_CTYPE_INLINES { + … +} + + +and: + + +cdl_package CYGPKG_LIBC { + … + + cdl_component CYGPKG_LIBC_STRING { + … + } + + cdl_option CYGPKG_LIBC_CTYPE_INLINES { + … + } +} + + +If a script defines options both inside and outside the body of the +&cdl-package; then the ones inside will be processed first. Language +purists may argue that it would have been better if all contained +options and components had to go into the body, but in practice it is +often convenient to be able to skip this level of nesting and the +resulting behavior is still well-defined. + + +Components can also contain options and other &CDL; entities, in fact +that is what distinguishes them from options. These can be defined in +the body of the &cdl-component; command: + + +cdl_component CYGPKG_LIBC_STDIO { + + cdl_component CYGPKG_LIBC_STDIO_FLOATING_POINT { + … + } + + cdl_option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS { + … + } +} + + +Nesting options inside the bodies of components like this is fine for +simple packages with only a limited number of configuration options, +but it becomes unsatisfactory as the number of options increases. +Instead it is possible to split the &CDL; data into multiple &CDL; +scripts, on a per-component basis. The &script; property should be +used for this. For example, in the case of the C library all +stdio-related configuration options could be put into +stdio.cdl, and the top-level CDL script +libc.cdl would contain the following: + + +cdl_package CYGPKG_LIBC { + … + + cdl_component CYGPKG_LIBC_STDIO { + … + script stdio.cdl + } +} + + +The CYGPKG_LIBC_STDIO_FLOATING_POINT component and +the CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS option +can then be placed at the top-level of stdio.cdl. +It is possible to have some options nested in the body of a +&cdl-component; command and other options in a separate file accessed +by the &script; property. In such a case the nested options would be +processed first, and then the other script would be read in. A script +specified by a &script; property should only define new options, +components or interfaces: it should not contain any additional +properties for the current component. + + +It is possible for a component's &CDL; script to have a sub-component +which also has a &script; property, and so on. In practice excessive +nesting like this is rarely useful. It is also possible to ignore the +&CDL; language support for constructing hierarchies automatically and +use the &parent; property explicitly for every single option and +component. Again this is not generally useful. + + + +At the time of writing interfaces cannot act as containers. This may +change in a future version of the component framework. If the change +is made then interfaces would support the &script; property, just like +components. + + + + + + + + + + + +CDL Properties + +Each package, component, option, and interface has a body of +properties, which provide the component framework with information +about how to handle each option. For example there is a property for a +descriptive text message which can be displayed to a user who is +trying to figure out just what effect manipulating the option would +have on the target application. There is another property for the +default value, for example whether a particular option should be +enabled or disabled by default. + + +All of the properties are optional, it is legal to define a +configuration option which has an empty body. However some properties +are more optional than others: users will not appreciate having to +manipulate an option if they are not given any sort of description or +documentation. Other properties are intended only for very specific +purposes, for example &make-object; and &include-files;, and are used +only rarely. + + +Because different properties serve very different purposes, their +syntax is not as uniform as the top-level commands. Some properties +take no arguments at all. Other properties take a single argument such +as a description string, or a list of arguments such as a &compile; +property which specifies the file or files that should be compiled if +a given option is active and enabled. The &define-proc; property takes +as argument a snippet of &Tcl; code. The &active-if;, &calculated;, +&default-value;, &legal-values; and &requires; properties take various +expressions. Additional properties may be defined in future which take +new kinds of arguments. + + +All property parsing code supports options for every property, +although at present the majority of properties do not yet take any +options. Any initial arguments that begin with a hyphen character +- will be interpreted as an option, for example: + + +cdl_package CYGPKG_HAL_ARM { + … + make -priority 1 { + … + } +} + + +If the option involves additional data, as for the +-priority example above, then this can be written +as either -priority=1 or as +-priority 1. On occasion the option parsing +code can get in the way, for example: + + +cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_STATE { + … + legal_values -1 to 1 + default_value -1 +} + + +Neither the &legal-values; nor the &default-value; property will +accept -1 as a valid option, so this will result in +syntax errors when the &CDL; script is read in by the component +framework. To avoid problems, the option parsing code will recognize +the string -- and will not attempt to interpret any +subsequent arguments. Hence this option should be written as: + + +cdl_option CYGNUM_LIBC_TIME_DST_DEFAULT_STATE { + … + legal_values -- -1 to 1 + default_value -- -1 +} + + +The property parsing code involves a recursive invocation of the Tcl +interpreter that is used to parse the top-level commands. This means +that some characters in the body of an option will be treated +specially. The # character can be used for +comments. The backslash character \, the +dollar character $, square brackets +[ and ], braces +{ and }, and the quote character +" may all receive special treatment. Most of the +time this is not a problem because these characters are not useful for +most properties. On occasion having a &Tcl; interpreter around +performing the parser can be very powerful. For more details of +how the presence of a &Tcl; interpreter can affect &CDL; scripts, +see . + + +Many of the properties can be used in any of &cdl-package;, +&cdl-component;, &cdl-option; or &cdl-interface;. Other properties are +more specific. The &script; property is only relevant to components. +The &define-header;, &hardware;, &include-dir;, &include-files;, and +&library; properties apply to a package as a whole, so can only occur +in the body of a &cdl-package; command. The &calculated;, +&default-value;, &legal-values; and &flavor; properties are not +relevant to packages, as will be explained later. The &calculated; and +&default-value; properties are also not relevant to interfaces. + + +This section lists the various properties, grouped by purpose. Each +property also has a full reference page in . +Properties related to values and expressions are described in more +detail in . Properties related to +header file generation and to the build process are described in +. + + + + + + +Information-providing Properties + +Users can only be expected to manipulate configuration options +sensibly if they are given sufficient information about these options. +There are three properties which serve to explain an option in plain +text: the &display; property gives +a textual alias for an option, which is usually more comprehensible +than something like CYGPKG_LIBC_TIME_ZONES`; the +&description; property gives a +longer description, typically a paragraph or so; the &doc; property specifies the location of +additional on-line documentation related to a configuration option. In +the context of a graphical tool the &display; string will be the +primary way for users to identify configuration options; the +&description; paragraph will be visible whenever the option is +selected; the on-line documentation will only be accessed when the +user explicitly requests it. + + +cdl_package CYGPKG_UITRON { + display "uITRON compatibility layer" + doc ref/ecos-ref.a.html + description " + eCos supports a uITRON Compatibility Layer, providing + full Level S (Standard) compliance with Version 3.02 of + the uITRON Standard, plus many Level E (Extended) features. + uITRON is the premier Japanese embedded RTOS standard." + … +} + + +All three properties take a single argument. For &display; and +&description; this argument is just a string. For &doc; it should be a +pointer to a suitable HTML file, optionally including an anchor within +that page. If the directory layout +conventions are observed then the component framework will look +for the HTML file in the package's doc sub-directory, otherwise the &doc; +filename will be treated as relative to the package's top-level directory. + + + + + + + +The Configuration Hierarchy + +There are two properties related to the hierarchical organization of +components and options: &parent; and +&script;. + + +The &parent; property can be used to move a &CDL; entity somewhere +else in the hierarchy. The most common use is for packages, to avoid +having all the packages appear at the top-level of the configuration +hierarchy. For example an architectural HAL package such as +CYGPKG_HAL_SH is placed below the common HAL +package CYGPKG_HAL using a &parent; property. + + +cdl_package CYGPKG_HAL_SH { + display "SH architecture" + parent CYGPKG_HAL + … +} + + +The &parent; property can also be used in the body of a +&cdl-component;, &cdl-option; or &cdl-interface;, but this is less +common. However care has to be taken since excessive re-parenting can +be confusing. Care also has to be taken when reparenting below some +other package that may not actually be loaded in a given +configuration, since the resulting behavior is undefined. + + +As a special case, if the parent is the empty string then the +&CDL; entity is placed at the root of the hierarchy. This is useful +for global preferences, default compiler flags, and other settings +that may affect every package. + + +The &script; property can only be used in the body of a +&cdl-component; command. The property takes a single filename as +argument, and this should be another &CDL; script containing +additional options, sub-components and interfaces that should go below +the current component in the hierarchy. If the directory layout conventions are +observed then the component framework will look for the specified file +relative to the cdl +subdirectory of the package, otherwise the filename will be treated as +relative to the package's top-level directory. + + +cdl_component CYGPKG_LIBC_STDIO { + display "Standard input/output functions" + flavor bool + requires CYGPKG_IO + requires CYGPKG_IO_SERIAL_HALDIAG + default_value 1 + description " + This enables support for standard I/O functions from <stdio.h>." + + script stdio.cdl +} + + + + + + + + +Value-related Properties + +There are seven properties which are related to option values and +state: &flavor;, +&calculated;, +&default-value;, +&legal-values;, +&active-if;, +&implements;, and +&requires;. More detailed +information can be found in . + + +In the context of configurability, the concept of an option's value is +somewhat non-trivial. First an option may or may not be loaded: it is +possible to build a configuration which has the math library but not +the kernel; however the math library's &CDL; scripts still reference +kernel options, for example +CYGSEM_LIBM_THREAD_SAFE_COMPAT_MODE has a +&requires; constraint on +CYGVAR_KERNEL_THREADS_DATA. Even if an option is +loaded it may or may not be active, depending on what is happening +higher up in the hierarchy: if the C library's +CYGPKG_LIBC_STDIO component is disabled then some +other options such as CYGNUM_LIBC_STDIO_BUFSIZE +become irrelevant. In addition each option has both a boolean +enabled/disabled flag and a data part. For many options only the +boolean flag is of interest, while for others only the data part is of +interest. The &flavor; property can be used to control this: + + + +flavor none + + +This flavor indicates that neither the boolean nor the data parts are +user-modifiable: the option is always enabled and the data is always +set to 1. The most common use for this is to have a +component that just acts as a placeholder in the hierarchy, allowing +various options to be grouped below it. + + + + +flavor bool + + +Only the boolean part of the option is user-modifiable. The data part +is fixed at 1. + + + + +flavor data + + +Only the data part of the option is user-modifiable. The boolean part +is fixed at enabled. + + + + +flavor booldata + + +Both the boolean and the data part of the option are user-modifiable. + + + + + +For more details of &CDL; flavors and how a flavor affects expression +evaluation, and other consequences, see . The &flavor; property cannot be used for a +package because packages always have the booldata +flavor. Options and components have the bool flavor +by default, since most configuration choices are simple yes-or-no +choices. Interfaces have the data flavor by default. + + +The &calculated; property can be used for options which should not be +user-modifiable, but which instead are fixed by the target hardware or +determined from the current values of other options. In general +&calculated; options should be avoided, since they can be confusing to +users who need to figure out whether or not a particular option can +actually be changed. There are a number of valid uses for &calculated; +options, and quite a few invalid ones as well. The reference packages should be consulted +for further details. The property takes an ordinary &CDL; expression as +argument, for example: + + +# A constant on some target hardware, perhaps user-modifiable on other +# targets. +cdl_option CYGNUM_HAL_RTC_PERIOD { + display "Real-time clock period" + flavor data + calculated 12500 +} + + +The &calculated; property cannot be used for packages or interfaces. +The value of a package always corresponds to the version of that +package which is loaded, and this is under user control. Interfaces +are implicitly calculated, based on the number of active and enabled +implementors. + + +The &default-value; property is similar to &calculated;, but only +specifies a default value which users can modify. Again this property +is not relevant to packages or interfaces. A typical example would be: + + +cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT { + display "Include GDB multi-threading debug support" + requires CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT + default_value CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT + … +} + + +The &legal-values; property imposes a constraint on the possible +values of the data part of an option. Hence it is only applicable to +options with the data or +booldata flavors. It cannot be used for a package +since the only valid value for a package is its version number. The +arguments to the &legal-values; property should constitute a &CDL; list expression. + + +cdl_option CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET { + display "Default Standard Time offset" + flavor data + legal_values -- -90000 to 90000 + default_value -- 0 + … +} + + +The &active-if; property does not relate directly to an option's +value, but rather to its active state. Usually this is controlled via +the configuration hierarchy: if the +CYGPKG_LIBC_STDIO component is disabled then all +options below it are inactive and do not have any consequences. +In some cases the hierarchy does not provide sufficient control, for +example an option should only be active if two disjoint sets of +conditions are satisfied: the hierarchy could be used for one of these +conditions, and an additional &active-if; property could be used for +the other one. The arguments to &active-if; should constitute a +&CDL; goal expression. + + +# Do not provide extra semaphore debugging if there are no semaphores +cdl_option CYGDBG_KERNEL_INSTRUMENT_BINSEM { + active_if CYGPKG_KERNEL_SYNCH + … +} + + +The &implements; property is related to the concept of &CDL; interfaces. If an option is +active and enabled and it implements a particular interface then it +contributes 1 to that interface's value. + + +cdl_package CYGPKG_NET_EDB7XXX_ETH_DRIVERS { + display "Cirrus Logic ethernet driver" + implements CYGHWR_NET_DRIVERS + implements CYGHWR_NET_DRIVER_ETH0 + … +} + + +The &requires; property is used to impose constraints on the user's +choices. For example it is unreasonable to expect the C library to +provide thread-safe implementations of certain functions if the +underlying kernel support has been disabled, or even if the kernel is +not being used at all. + + +cdl_option CYGSEM_LIBC_PER_THREAD_ERRNO { + display "Per-thread errno" + doc ref/ecos-ref.15.html + requires CYGVAR_KERNEL_THREADS_DATA + default_value 1 + … +} + + +The arguments to the &requires; property should be a &CDL; goal expression. + + + + + + + + +Generating the Configuration Header Files + +When creating or updating a build tree the component framework will +also generate configuration header files, one per package. By default +it will generate a #define for each option, +component or interface that is active and enabled. For options with +the data or booldata flavors the +#define will use the option's data part, otherwise +it will use the constant 1. Typical output would +include: + + +#define CYGFUN_LIBC_TIME_POSIX 1 +#define CYGNUM_LIBC_TIME_DST_DEFAULT_STATE -1 + + +There are six properties which can be used to control the header file +generation process: +&define-header;, +&no-define;, +&define-format;, +&define;, +&if-define;, and +&define-proc;. + + +By default the component framework will generate a configuration +header file for each package based on the package's name: everything +up to and including the first underscore is discarded, the rest of the +name is lower-cased, and a .h suffix is appended. +For example the configuration header file for the kernel package +CYGPKG_KERNEL is pkgconf/kernel.h. The &define-header; +property can be used to specify an alternative filename. This applies +to all the components and options within a package, so it can only be +used in the body of a &cdl-package; command. For example the following +specifies that the configuration header file for the SPARClite HAL +package is pkgconf/hal_sparclite.h. + + +cdl_package CYGPKG_HAL_SPARCLITE { + display "SPARClite architecture" + parent CYGPKG_HAL + hardware + define_header hal_sparclite.h + … +} + + + +At present the main use for the &define-header; property is related +to hardware packages, see the reference +pages for more details. + + + +The &no-define; property is used to suppress the generation of the +default #define. This can be useful if an option's +consequences are all related to the build process or to constraints, +and the option is never actually checked in any source code. It can +also be useful in conjunction with the &define;, &if-define; or +&define-proc; properties. The &no-define; property does not take any +arguments. + + +cdl_component CYG_HAL_STARTUP { + display "Startup type" + flavor data + legal_values { "RAM" "ROM" } + default_value {"RAM"} + no_define + define -file system.h CYG_HAL_STARTUP + … +} + + +This example also illustrates the &define; property, which can be used +to generate a #define in addition to the default +one. It takes a single argument, the name of the symbol to be defined. +It also takes options to control the configuration header file in +which the symbol should be defined and the format to be used. + + +The &define-format; property can be used to control how the value part +of the default #define gets formatted. For example +a format string of "0x%04x" could be used to +generate a four-digit hexadecimal number. + + +The &if-define; property is intended for use primarily to control +assertions, tracing, and similar functionality. It supports a specific +implementation model for these, allowing control at the grain of +packages or even individual source files. The reference pages provide additional +information. + + +The &define-proc; property provides an escape mechanism for those +cases where something special has to happen at configuration header +file generation time. It takes a single argument, a fragment of &Tcl; +code, which gets executed when the header file is generated. This code +can output arbitrary data to the header file, or perform any other +actions that might be appropriate. + + + + + + + + +Controlling what gets Built + +There are six properties which affect the build process: +&compile;, +&make;, +&make-object;, +&library;, +&include-dir;, and +&include-files;. +The last three apply to a package as a whole, and can only occur in +the body of a &cdl-package; command. + + +Most of the source files that go into a package should simply be +compiled with the appropriate compiler, selected by the target +architecture, and with the appropriate flags, with an additional set +defined by the target hardware and possible modifications on a +per-package basis. The resulting object files will go into the library +libtarget.a, which can then be linked against +application code. The &compile; property is used to list these source +files: + + +cdl_package CYGPKG_ERROR { + display "Common error code support" + compile strerror.cxx + include_dir cyg/error + … +} + + +The arguments to the &compile; property should be one or more source +files. Typically most of the sources will be needed for the package as +a whole, and hence they will be listed in one or more &compile; +properties in the body of the &cdl-package;. Some sources may be +specific to particular configuration options, in other words there is +no point in compiling them unless that option is enabled, in which +case the sources should be listed in a &compile; property in the +corresponding &cdl-option;, &cdl-component; or &cdl-interface; body. + + +Some packages may have more complicated build requirements, for +example they may involve a special target such as a linker script +which should not end up in the usual library, or they may involve +special build steps for generating an object file. The &make; and +&make-object; properties provide support for such requirements, for +example: + + +cdl_package CYGPKG_HAL_MN10300_AM33 { + display "MN10300 AM33 variant" + … + make { + <PREFIX>/lib/target.ld: <PACKAGE>/src/mn10300_am33.ld + $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) \ + $(CFLAGS) -o $@ $< + @echo $@ ": \\" > $(notdir $@).deps + @tail +2 target.tmp >> $(notdir $@).deps + @echo >> $(notdir $@).deps + @rm target.tmp + } +} + + +For full details of custom build steps and the build process +generally, see . + + +By default all object files go into the library +libtarget.a. It is possible to override this at +the package level using the &library; property, but this should be +avoided since it complicates application development: instead of just +linking with a single library for all &eCos;-related packages, it +suddenly becomes necessary to link with several libraries. + + +The &include-dir; and &include-files; properties relate to a package's +exported header files. By default a package's header files will be +exported to the install/include +directory. This is the desired behavior for some packages like the C +library, since headers like stdio.h should exist at that level. +However if all header files were to end up in that directory then +there would be a significant risk of a name clash. Instead it is +better for packages to specify some sub-directory for their exported +header files, for example: + + +cdl_package CYGPKG_INFRA { + display "Infrastructure" + include_dir cyg/infra + … +} + + +The various header files exported by the infrastructure, for example +cyg_ass.h and cyg_trac.h will now end up in the +install/include/cyg/infra +sub-directory, where a name clash is very unlikely. + + +For packages which follow the directory layout conventions the +component framework will assume that the package's +include sub-directory contains +all exported header files. If this is not the case, for example +because the package is sufficiently simple that the layout convention +is inappropriate, then the exported header files can be listed +explicitly in an &include-files; property. + + + + + + + + +Miscellaneous Properties + +The &hardware; property is +only relevant to packages. Some packages such as device drivers and +HAL packages are hardware-specific, and generally it makes no sense to +add such packages to a configuration unless the corresponding hardware +is present on your target system. Typically hardware package selection +happens automatically when you select your target. The &hardware; +property should be used to identify a hardware-specific package, and +does not take any arguments. + + +cdl_package CYGPKG_HAL_MIPS { + display "MIPS architecture" + parent CYGPKG_HAL + hardware + include_dir cyg/hal + define_header hal_mips.h + … +} + + +At present the &hardware; property is largely ignored by the component +framework. This may change in future releases. + + + + + + + + + + + +Option Naming Convention + +All the options in a given configuration live in the same namespace. +Furthermore it is not possible for two separate options to have the +same name, because this would make any references to those options in +&CDL; expressions ambiguous. A naming convention exists to avoid +problems. It is recommended that component writers observe some or all +of this convention to reduce the probability of name clashes with +other packages. + + +There is an important restriction on option names. Typically the +component framework will output a #define for every +active and enabled option, using the name as the symbol being defined. +This requires that all names are valid C preprocessor symbols, a +limitation that is enforced even for options which have the +&no-define; property. Preprocessor symbols can be any sequence of +lower case letters a-z, upper +case letters, A-Z, the +underscore character _, and the digits +0-9. The first character must be +a non-digit. Using an underscore as the first character is +discouraged, because that may clash with reserved language +identifiers. In addition there is a convention that preprocessor +symbols only use upper case letters, and some component writers may +wish to follow this convention. + + +A typical option name could be something like +CYGSEM_KERNEL_SCHED_BITMAP. This name consists of +several different parts: + + + + +The first few characters, in this case the three letters +CYG, are used to identify the organization that +produced the package. For historical reasons packages produced by Red +Hat tend to use the prefix CYG rather than +RHAT. Component writers should use their own +prefix: even when cutting and pasting from an existing &CDL; script +the prefix should be changed to something appropriate to their +organization. + + +It can be argued that a short prefix, often limited to upper case +letters, is not sufficiently long to eliminate the possibility of +name clashes. A longer prefix could be used, for example one based on +internet domain names. However the C preprocessor has no concept of +namespaces or import directives, so it would always +be necessary to use the full option name in component source code +which gets tedious - option names tend to be long enough as it is. +There is a small increased risk of name clashes, but this risk is felt +to be acceptable. + + + + +The next three characters indicate the nature of the option, for +example whether it affects the interface or just the implementation. A +list of common tags is given below. + + + + +The KERNEL_SCHED part indicates the location of the +option within the overall hierarchy. In this case the option is part of +the scheduling component of the kernel package. Having the hierarchy +details as part of the option name can help in understanding +configurable code and further reduces the probability of a name clash. + + + + +The final part, BITMAP, identifies the option +itself. + + + + +The three-character tag is intended to provide some additional +information about the nature of the option. There are a number of +pre-defined tags. However for many options there is a choice: +options related to the platform should normally use +HWR, but numerical options should normally use +NUM; a platform-related numerical option such as +the size of an interrupt stack could therefore use either tag. +There are no absolute rules, and it is left to component writers to +interpret the following guidelines: + + + +xxxARC_ + +The ARC tag is intended for options related +to the processor architecture. Typically such options will only occur +in architectural or variant HAL packages. + + + +xxxHWR_ + +The HWR tag is intended for options related to +the specific target board. Typically such options will only occur in +platform HAL packages. + + + +xxxPKG_ + +This tag is intended for packages or components, in other words +options which extend the configuration hierarchy. Arguably a +COM tag would be more appropriate for +components, but this could be confusing because of the considerable +number of computing terms that begin with com. + + + +xxxGLO_ + +This is intended for global configuration options, especially +preferences. + + + +xxxDBG_ + +The DBG tag indicates that the option is in +some way related to debugging, for example it may enable assertions in +some part of the system. + + + +xxxTST_ + +This tag is for testing-related options. Typically these do not +affect actual application code, instead they control the interaction +between target-side test cases and a host-side testing infrastructure. + + + +xxxFUN_ + +This is for configuration options which affect the interface of a +package. There are a number of related tag which are also +interface-related. xxxFUN_ is intended primarily +for options that control whether or not one or more functions are +provided by the package, but can also be used if none of the other +interface-related tags is applicable. + + + +xxxVAR_ + +This is analogous to FUN but controls the presence +or absence of one or more variables or objects. + + + +xxxCLS_ + +The CLS tag is intended only for packages that +provide an object-oriented interface, and controls the presence or +absence of an entire class. + + + +xxxMFN_ + +This is also for object-orientated interfaces, and indicates the +presence or absence of a member function rather than an entire class. + + + +xxxSEM_ + +A SEM option does not affect the interface (or if +does affect the interface, this is incidental). Instead it is used for +options which have a fundamental effect on the semantic behavior of a +package. For example the choice of kernel schedulers is semantic in +nature: it does not affect the interface, in particular the function +cyg_thread_create exists irrespective of which +scheduler has been selected. However it does have a major impact on +the system's behavior. + + + +xxxIMP_ + +IMP is for implementation options. These do not +affect either the interface or the semantic behavior (with the +possible exception of timing-related changes). A typical +implementation option controls whether or not a particular function or +set of functions should get inlined. + + + +xxxNUM_ + +This tag is for numerical options, for example the number of +scheduling priority levels. + + + +xxxDAT_ + +This is for data items that are not numerical in nature, for example a +device name. + + + +xxxBLD_ + +The BLD tag indicates an option that affects +the build process, for example compiler flag settings. + + + +xxxINT_ + +This should normally be used for &CDL; interfaces, which is a language +construct that is largely independent from the interface exported by a +package via its header files. For more details of &CDL; interfaces +see . + + + +xxxPRI_ + +This tag is not normally used for configuration options. Instead +it is used by &CDL; scripts to pass additional private information to +the source code via the configuration header files, typically inside a +&define-proc; property. + + + +xxxSRC_ + +This tag is not normally used for configuration options. Instead +it can be used by package source code to interact with such options, +especially in the context of the &if-define; property. + + + + + +There is one special case of a potential name clash that is worth +mentioning here. When the component framework generates a +configuration header file for a given package, by default it will use +a name derived from the package name (the &define-header; property can +be used to override this). The file name is constructed from the +package name by removing everything up to and including the first +underscore, converting the remainder of the name to lower case, and +appending a .h suffix. For example the kernel +package CYGPKG_KERNEL will involve a header file +pkgconf/kernel.h. If a +configuration contained some other package +XYZPKG_KERNEL then this would attempt to use the +same configuration header file, with unfortunate effects. Case +sensitivity could introduce problems as well, so a package +xyzpkg_kernel would involve the same problem. Even +if the header file names preserved the case of the package name, not +all file systems are case sensitive. There is no simple solution to +this problem. Changing the names of the generated configuration header +files would involve a major incompatible change to the interface, to +solve a problem which is essentially hypothetical in nature. + + + + + + + + +An Introduction to Tcl + + +All &CDL; scripts are implemented as &Tcl; scripts, and are read in by +running the data through a standard &Tcl; interpreter, extended with a +small number of additional commands such as +cdl_option and cdl_component. +Often it is not necessary to know the full details of &Tcl; syntax. +Instead it is possible to copy an existing script, perform some copy +and paste operations, and make appropriate changes to names and to +various properties. However there are also cases where an +understanding of &Tcl; syntax is very desirable, for example: + + + +cdl_option CYGDAT_UITRON_MEMPOOLFIXED_EXTERNS { + display "Externs for initialization" + flavor data + default_value {"static char fpool1[ 2000 ], \\\n\ + fpool2[ 2000 ], \\\n\ + fpool3[ 2000 ];"} + … +} + + + +This causes the &cdl-option; command to be executed, which in turn +evaluates its body in a recursive invocation of the &Tcl; interpreter. +When the &default-value; property is encountered the braces around the +value part are processed by the interpreter, stopping it from doing +further processing of the braced contents (except for backslash +processing at the end of a line, that is special). In particular it +prevents command substitution for +[ 2000 ]. A single argument will be +passed to the &default-value; command which expects a &CDL; +expression, so the expression parsing code is passed the following: + + + +"static char fpool1[ 2000 ], \\\n fpool2[ 2000 ], \\\n fpool3[ 2000 ];" + + + +The &CDL; expression parsing code will treat this as a simple string +constant, as opposed to a more complicated expression involving other +options and various operators. The string parsing code will perform +the usual backslash substitutions so the actual default value will be: + + +static char fpool1[ 2000 ], \ + fpool2[ 2000 ], \ + fpool3[ 2000 ]; + + + +If the user does not modify the option's value then the following +will be generated in the appropriate configuration header file: + + +#define CYGDAT_UITRON_MEMPOOLFIXED_EXTERNS static char fpool1[ 2000 ], \ + fpool2[ 2000 ], \ + fpool3[ 2000 ]; + + + +Getting this desired result usually requires an understanding of both +&Tcl; syntax and &CDL; expression syntax. Sometimes it is possible to +substitute a certain amount of trial and error instead, but this may +prove frustrating. It is also worth pointing out that many &CDL; +scripts do not involve this level of complexity. On the other hand, +some of the more advanced features of the &CDL; language involve +fragments of &Tcl; code, for example the &define-proc; property. To +use these component writers will need to know about the full &Tcl; +language as well as the syntax. + + +Although the current example may seem to suggest that &Tcl; is rather +complicated, it is actually a very simple yet powerful scripting +language: the syntax is defined by just eleven rules. On occasion this +simplicity means that Tcl's behavior is subtly different from other +languages, which can confuse newcomers. + + +When the Tcl interpreter is passed some data such as +puts Hello, it splits this data into a command +and its arguments. The command will be terminated by a newline or by a +semicolon, unless one of the quoting mechanisms is used. The command +and each of its arguments are separated by white space. So in the +following example: + + +puts Hello +set x 42 + + +This will result in two separate commands being executed. The first +command is puts and is passed a single argument, +Hello. The second command is set +and is passed two arguments, x and +42. The intervening newline character serves to +terminate the first command, and a semi-colon separator could be used +instead: + + +puts Hello;set x 42 + + +Any white space surrounding the semicolon is just ignored because it +does not serve to separate arguments. + + +Now consider the following: + + +set x Hello world + + +This is not valid &Tcl;. It is an attempt to invoke the +set command with three arguments: +x, Hello, and +world. The set only takes two +arguments, a variable name and a value, so it is necessary to combine +the data into a single argument by quoting: + + +set x "Hello world" + + +When the &Tcl; interpreter encounters the first quote character it +treats all subsequent data up to but not including the closing quote +as part of the current argument. The quote marks are removed by the +interpreter, so the second argument passed to the +set command is just Hello world +without the quote characters. This can be significant in the context +of &CDL; scripts. For example: + + +cdl_option CYG_HAL_STARTUP { + … + default_value "RAM" +} + + +The &Tcl; interpreter strips off the quote marks so the &CDL; +expression parsing code sees RAM instead of +"RAM". It will treat this as a reference to +some unknown option RAM rather than as a string +constant, and the expression evaluation code will use a value of +0 when it encounters an option that is not +currently loaded. Therefore the option +CYG_HAL_STARTUP ends up with a default value of +0. Either braces or backslashes should be used to +avoid this, for example +default_value { "RAM" }. + + + +There are long-term plans to implement some sort of &CDL; validation +utility cdllint which +could catch common errors like this one. + + + +A quoted argument continues until the closing quote character is +encountered, which means that it can span multiple lines. Newline or +semicolon characters do not terminate the current command in such +cases. &description; properties usually make use of this: + + +cdl_package CYGPKG_ERROR { + description " + This package contains the common list of error and + status codes. It is held centrally to allow + packages to interchange error codes and status + codes in a common way, rather than each package + having its own conventions for error/status + reporting. The error codes are modelled on the + POSIX style naming e.g. EINVAL etc. This package + also provides the standard strerror() function to + convert error codes to textual representation." + … +} + + +The &Tcl; interpreter supports much the same forms of backslash +substitution as other common programming languages. Some backslash +sequences such as \n will be replaced by the +appropriate character. The sequence \\ will be +replaced by a single backslash. A backslash at the very end of a line +will cause that backslash, the newline character, and any white space +at the start of the next line to be replaced by a single space. Hence +the following two Tcl commands are equivalent: + + +puts "Hello\nworld\n" +puts \ +"Hello +world +" + + +If a &description; string needs to contain quote marks or other +special characters then backslash escapes can be used. In addition to +quote and backslash characters, the Tcl interpreter treats square +brackets, the $ character, and braces specially. +Square brackets are used for command substitution, for example: + + +puts "The answer is [expr 6 * 9]" + + +When the Tcl interpreter encounters the square brackets it will treat +the contents as another command that should be executed first, and the +result of executing that is used when continuing to process the +script. In this case the Tcl interpreter will execute the command +expr 6 * 9, yielding a result of 42 + + +It is possible that some versions of the Tcl interpreter will instead +produce a result of 54 when asked to multiply six by nine. Appropriate +reference +documentation should be consulted for more information on why +42 is in fact the correct answer. + + +and then the +Tcl interpreter will execute puts "The answer is 42". +It should be noted that the interpreter performs only one level +of substitution: if the result of performing command substitution +performs further special characters such as square brackets then these +will not be treated specially. + + +Command substitution will not prove useful for many &CDL; scripts, +except for e.g. a &define-proc; property which involves a fragment of +&Tcl; code. Potentially there are some interesting uses, for example +to internationalize &display; strings. However care does have to be +taken to avoid unexpected command substitution, for example if an +option description involves square brackets then typically these would +require backslash-escapes. + + +The $ character is used in Tcl scripts to perform +variable substitution: + + +set x [expr 6 * 9] +puts "The answer is $x" + + +Variable substitution, like command substitution, is unlikely to +prove useful for many &CDL; scripts except in the context of +&Tcl; fragments. If it is necessary to have a $ +character then a backslash escape may have to be used. + + +Braces are used to collect a sequence of characters into a single +argument, just like quotes. The difference is that variable, command +and backslash substitution do not occur inside braces (with the +sole exception of backslash substitution at the end of a line). +Therefore given a line in a &CDL; script such as: + + +default_value {"RAM"} + + +The braces are stripped off by the &Tcl; interpreter, leaving +"RAM" which will be handled as a string constant by +the expression parsing code. The same effect could be achieved using +one of the following: + + +default_value \"RAM\" +default_value "\"RAM\"" + + +Generally the use of braces is less confusing. At this stage it is +worth noting that the basic format of &CDL; data makes use of +braces: + + +cdl_option <name> { + … +}; + + +The &cdl-option; command is passed two arguments, a name and a body, +where the body consists of everything inside the braces but not the +braces themselves. This body can then be executed in a recursive +invocation of the &Tcl; interpreter. If a &CDL; script contains +mismatched braces then the interpreter is likely to get rather +confused and the resulting diagnostics may be difficult to understand. + + +Comments in Tcl scripts are introduced by a hash character +#. However, a hash character only introduces a +comment if it occurs where a command is expected. Consider the +following: + + +# This is a comment +puts "Hello" # world + + +The first line is a valid comment, since the hash character occurs +right at the start where a command name is expected. The second line +does not contain a comment. Instead it is an attempt to invoke the +puts command with three arguments: +Hello, # and +world. These are not valid arguments for the +puts command so an error will be raised. +If the second line was rewritten as: + + +puts "Hello"; # world + + +then this is a valid Tcl script. The semicolon identifies the end of +the current command, so the hash character occurs at a point where the +next command would start and hence it is interpreted as the start of a +comment. + + +This handling of comments can lead to subtle behavior. Consider the +following: + + +cdl_option WHATEVER { +# This is a comment } + default_value 0 + … +} + + +Consider the way the Tcl interpreter processes this. The command name +and the first argument do not pose any special difficulties. The +opening brace is interpreted as the start of the next argument, which +continues until a closing brace is encountered. In this case the +closing brace occurs on the second line, so the second argument passed +to cdl_option is +\n    # This is a comment +. This second argument is processed in a recursive +invocation of the Tcl interpreter and does not contain any commands, +just a comment. Top-level script processing then resumes, and the next +command that is encountered is default_value. Since +the parser is not currently processing a configuration option this is +an error. Later on the Tcl interpreter would encounter a closing brace +by itself, which is also an error. + + +For component writers who need more information about &Tcl;, +especially about the language rather than the syntax, various +resources are available. A reasonable starting point is the +Scriptics developer +web site. + + + + + + + +Values and Expressions + + + + +It is fairly reasonable to expect that enabling or disabling a +configuration option such as +CYGVAR_KERNEL_THREADS_DATA in some way affects its +value. This will have an effect on any +expressions that reference this option such as +requires CYGVAR_KERNEL_THREADS_DATA. It will +also affect the consequences of that option: how it affects the build +process and what happens to any constraints that +CYGVAR_KERNEL_THREADS_DATA may impose (as opposed +to constraints on this option imposed by others). + + +In a language like C the handling of variables is relatively +straightforward. If a variable x gets referenced in +an expression such as if (x != 0), +and that variable is not defined anywhere, then the code will fail to +build, typically with an unresolved error at link-time. Also in C +a variable x does not live in any hierarchy, so its +value for the purposes of expression evaluation is not affected by +anything else. C variables also have a clear type such as +int or long double. + + +In &CDL; things are not so straightforward. + + + + + + + + +Option Values + + +There are four factors which go into an option's value: + + + + +An option may or may not be loaded. + + + + +If the option is loaded, it may or may not be active. + + + + +Even if the option is active, it may or may not be enabled. + + + + +If the option is loaded, active and enabled then it will have some +associated data which constitutes its value. + + + + + + + + +Is the Option Loaded? + + +At any one time a configuration will contain only a subset of all +possible packages. In fact it is impossible to combine certain +packages in a single configuration. For example architectural HAL +packages should contain a set of options defining endianness, the +sizes of basic data types and so on (many of which will of course be +constant for any given architecture). Any attempt to load two +architectural HAL packages into a configuration will fail because of +the resulting name clash. Since &CDL; expressions can reference +options in other packages, and often need to do so, it is essential to +define the resulting behavior. + + +One complication is that the component framework does not know about +every single option in every single package. Obviously it cannot know +about packages from arbitrary third parties which have not been +installed. Even for packages which have been installed, the current +repository database does not hold details of every option, only of the +packages themselves. If a &CDL; expression contains a reference to +some option CYGSEM_KERNEL_SCHED_TIMESLICE then the +component framework will only know about this option if the kernel +package is actually loaded into the current configuration. If the +package is not loaded then theoretically the framework might guess +that the option is somehow related to the kernel by examining the +option name but this would not be robust: the option could easily be +part of some other package that violates the naming convention. + + +Assume that the user is building a minimal configuration which does +not contain the kernel package, but does have other packages which +contain the following constraints: + + + requires CYGPKG_KERNEL + requires CYGPKG_KERNEL_THREADS_DATA + requires !CYGSEM_KERNEL_SCHED_TIMESLICE + + +Clearly the first constraint is not satisfied because the kernel is +not loaded. The second constraint is also not satisfied. The third +constraint is trivially satisfied: if there is no kernel then the +kernel's timeslicing support cannot possibly be enabled. + + +Any options which are not in the current configuration are handled as +follows: + + + + +Any references to that option will evaluate to 0, +so requires !CYGSEM_KERNEL_SCHED_TIMESLICE will +be satisfied but +requires CYGSEM_KERNEL_THREADS_DATA will not +be satisfied. + + + + +An option that is not loaded has no consequences on the build process. +It cannot directly result in any #define's in a +configuration header file, nor in any files being compiled. This is +only reasonable: if the option is not loaded then the component +framework has no way of knowing about any &compile; or similar +properties. An option that is not loaded can have indirect +consequences by being referenced in &CDL; expressions. + + + + +An option that is not loaded cannot impose any constraints on the rest +of the configuration. Again this is the only reasonable behavior: if +the option is not loaded then any associated &requires; or +&legal-values; properties will not be known. + + + + + + + + + + +Is the Option Active + + +The next issue to consider is whether or not a particular option is +active. Configuration options are organized in a hierarchy of +components and sub-components. For example the C library package +contains a component CYGPKG_LIBC_STDIO containing +all the options related to standard I/O. If a user disables the +component as a whole then all the options below it become inactive: it +makes no sense to disable all stdio functionality and then manipulate +the buffer sizes. + + +Inactive is not quite the same as disabled, although the effects are +similar. The value of an inactive option is preserved. If the user +modifies a buffer size option, then disables the whole stdio +component, the buffer size value remains in case the stdio component +is re-enabled later on. Some tools such as the graphical configuration +tool will treat inactive options specially, for example such options +may be grayed out. + + +The active or inactive state of an option may affect other packages. +For example a package may use the sprintf +function and require support for floating point conversions, a +constraint that is not satisfied if the relevant option is inactive. +It is necessary to define exactly what it means for an option to be +inactive: + + + + +An option is inactive if its parent is either inactive or disabled. +For example if CYGPKG_LIBC_STDIO is disabled then +all the options and sub-components become inactive; since +CYGPKG_LIBC_STDIO_FLOATING_POINT is now inactive, +CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT is inactive +as well. + + + + +Options may also be inactive as a result of an &active-if; property. +This is useful if a particular option is only relevant if two or more +disjoint sets of conditions need to be satisfied, since the +hierarchical structure can only cope with at most one such set. + + + + +If an option is inactive then any references to that option in &CDL; +expressions will evaluate to 0. Hence a constraint +of the form +requires CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT +is not satisfied if the entire stdio component is disabled. + + + + +An option that is inactive has no consequences on the build process. +No #define will be generated. Any &compile; or +similar properties will be ignored. + + + + +An option that is inactive cannot impose any constraints on the rest +of the configuration. For example +CYGSEM_LIBC_STDIO_PRINTF_FLOATING_POINT has a +dependency requires CYGPKG_LIBM, but if all of +the stdio functionality is disabled then this constraint is ignored +(although of course there may be other packages which have a +dependency on CYGPKG_LIBM. + + + + + + + + + +Is the Option Enabled? What is the Data? + + +The majority of configuration options are boolean in nature, so the +user can either enable or disable some functionality. Some options are +different. For example CYGNUM_LIBC_STDIO_BUFSIZE is +a number, and CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE is +a string corresponding to a device name. A few options like +CYGDAT_UITRON_TASK_EXTERNS can get very +complicated. &CDL; has to cope with this variety, and define the exact +behavior of the system in terms of constraints and build-time +consequences. + + +In &CDL; the value of an option consists of two parts. There is a +boolean part, controlling whether or not the option is enabled. There +is also a data part, providing additional information. For most +options one of these parts is fixed, as controlled by the option's +&flavor; property: + + + + + + Flavor + Enabled + Data + + + + none + Always enabled + 1, not modifiable + + + bool + User-modifiable + 1, not modifiable + + + data + Always enabled + User-modifiable + + + booldata + User-modifiable + User-modifiable + + + + + +The effects of the boolean and data parts are as follows: + + + + +If an option is disabled, in other words if the boolean part is false, +then any references to that option in &CDL; expressions will evaluate +to 0. This is the same behavior as for inactive +options. The data part is not relevant. The none +and data flavors specify that the option is always +enabled, in which case this rule is not applicable. + + + + +If an option is enabled then any references to that option in &CDL; +expressions will evaluate to the option's data part. For two of the +flavors, none and bool, this +data part is fixed to the constant 1 which +generally has the expected result. + + + + +If a component or package is disabled then all sub-components and +options immediately below it in the hierarchy are inactive. By a +process of recursion this will affect all the nodes in the subtree. + + + + +If an option is disabled then it can impose no constraints on the rest +of the configuration, in particular &requires; and &legal-values; +properties will be ignored. If an option is enabled then its +constraints should be satisfied, or the component framework will +report various conflicts. Note that the &legal-values; constraint only +applies to the data part of the option's value, so it is only useful +with the data and booldata +flavors. Options with the none and +data flavors are always enabled so their +constraints always have to be satisfied (assuming the option is +active). + + + + +If an option is disabled then it has no direct consequences at +build-time: no #define will be generated, no files +will get compiled, and so on. If an option is active and enabled then +all the consequences take effect. The option name and data part are +used to generate the #define in the appropriate +configuration header file, subject to various properties such as +&no-define;, but the data part has no other effects on the build +system. + + + + +By default all options and components have the bool +flavor: most options are boolean in nature, so making this the default +allows for slightly more compact &CDL; scripts. Packages have the +booldata flavor, where the data part always +corresponds to the version of the package that is loaded into the +configuration: changing this value corresponds to unloading the old +version and loading in a different one. + + + +&CDL; Flavors + +The concept of &CDL; flavors tends to result in various discussions +about why it is unnecessarily complicated, and would it not have been +easier to do … However there are very good reasons why CDL +works the way it does. + + +The first common suggestion is that there is no need to have separate +flavors bool, data, and so on. A +boolean option could just be handled as a data option with legal +values 0 and 1. The counter +arguments are as follows: + + + + +It would actually make &CDL; scripts more verbose. By default all +options and components have the bool flavor, since +most options are boolean in nature. Without a bool +flavor it would be necessary to indicate explicitly what the legal +values are somehow, e.g. with a &legal-values; property. + + + + +The boolean part of an option's value has a very different effect from +the data part. If an option is disabled then it has no consequences at +build time, and can impose no constraints. A data +option always has consequences and can impose constraints. To get the +desired effect it would be necessary to add &CDL; data indicating that +a value of 0 should be treated specially. Arguably +this could be made built-in default behavior, although that would +complicate options where 0 is a perfectly legal +number, for example +CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET. + + + + +There would no replacement for a booldata option +for which 0 is a valid value. Again some additional +&CDL; syntax would be needed to express such a concept. + + + + +Although initially it may seem confusing that an option's value has +both a boolean and a data part, it is an accurate reflection of how +configuration options actually work. The various alternatives would +all make it harder to write &CDL; scripts. + + +The next common suggestion is that the data part of a value should be +typed in much the same way as C or C++ data types. For example it +should be possible to describe +CYGNUM_LIBC_STDIO_BUFSIZE as an integer value, +rather than imposing &legal-values; constraints. Again there are very +good reasons why this approach was not taken: + + + + +The possible legal values for an integer are rarely correct for a +&CDL; option. A constraint such as +1 to 0x7fffffff is a bit more accurate, +although if this option indicates a buffer size it is still not +particularly good — very few targets will have enough +memory for such a buffer. Forcing &CDL; writers to list the +&legal-values; constraints explicitly should make them think a bit +more about what values are actually sensible. For example +CYGNUM_LIBC_TIME_DST_DEFAULT_OFFSET has legal +values in the range -90000 to 90000, +which helps the user to set a sensible value. + + + + +Not all options correspond to simple data types such as integers. +CYGDAT_LIBC_STDIO_DEFAULT_CONSOLE is a C string, +and would have to be expressed using something like +char []. This introduces plenty of +opportunities for confusion, especially since square brackets may get +processed by the &Tcl; interpreter for command substitution. + + + + +Some configuration options can get very complicated indeed, for +example the default value of +CYGDAT_UITRON_TASK_INITIALIZERS is: + + +CYG_UIT_TASK( "t1", 1, task1, &stack1, CYGNUM_UITRON_STACK_SIZE ), \ +CYG_UIT_TASK( "t2", 2, task2, &stack2, CYGNUM_UITRON_STACK_SIZE ), \ +CYG_UIT_TASK( "t3", 3, task3, &stack3, CYGNUM_UITRON_STACK_SIZE ), \ +CYG_UIT_TASK( "t4", 4, task4, &stack4, CYGNUM_UITRON_STACK_SIZE ) + + +This would require &CDL; knowing about C macros, structures, arrays, +static initializers, and so on. Adding such detailed knowledge about +the C language to the component framework is inappropriate. + + + + +&CDL; needs to be usable with languages other than C. At present this +includes C++, in future it may include languages such as Java. Each +language adds new data types and related complications, for example +C++ classes and inheritance. Making &CDL; support a union of all data +types in all possible languages is not sensible. + + + + +The &CDL; approach of treating all data as a sequence of characters, +possibly constrained by a &legal-values; property or other means, has +the great advantage of simplicity. It also fits in with the &Tcl; +language that underlies &CDL;. + + + + + + + + + +Some Examples + + +The following excerpt from the C library's &CDL; scripts can be used +to illustrate how values and flavors work in practice: + + +cdl_component CYGPKG_LIBC_RAND { + flavor none + compile stdlib/rand.cxx + + cdl_option CYGSEM_LIBC_PER_THREAD_RAND { + requires CYGVAR_KERNEL_THREADS_DATA + default_value 0 + } + + cdl_option CYGNUM_LIBC_RAND_SEED { + flavor data + legal_values 0 to 0x7fffffff + default_value 1 + } + + cdl_option CYGNUM_LIBC_RAND_TRACE_LEVEL { + flavor data + legal_values 0 to 1 + default_value 0 + } +} + + +If the application does not require any C library functionality then +it is possible to have a configuration where the C library is not +loaded. This can be achieved by starting with the minimal template, or +by starting with another template such as the default one and then +explicitly unloading the C library package. If this package is not +loaded then any references to the CYGPKG_LIBC_RAND +component or any of its options will have a value of +0 for the purposes of expression evaluation. No +#define's will be generated for the component or +any of its options, and the file stdlib/rand.cxx +will not get compiled. There is nothing special about the C library +here, exactly the same would apply for say a device driver that does +not correspond to any of the devices on the target hardware. + + +Assuming the C library is loaded, the next thing to consider is +whether or not the component and its options are active. The component +is layered immediately below the C library package itself, so if the +package is loaded then it is safe to assume that the package is also +enabled. Therefore the parent of CYGPKG_LIBC_RAND +is active and enabled, and in the absence of any &active-if; +properties CYGPKG_LIBC_RAND will be active as well. + + +The component CYGPKG_LIBC_RAND has the flavor +none. This means the component cannot be disabled. +Therefore all the options in this component have an active and enabled +parent, and in the absence of any &active-if; properties they are all +active as well. + + +The component's flavor none serves to group +together all of the configuration options related to random number +generation. This is particularly useful in the context of the +graphical configuration tool, but it also helps when it comes to +naming the options: all of the options begin with +CYGxxx_LIBC_RAND, giving a clear hint about both +the package and the component within that package. The flavor means +that the component is always enabled and has the value +1 for the purposes of expression evaluation. There +will always be a single #define of the form: + + +#define CYGPKG_LIBC_RAND 1 + + +In addition the file stdlib/rand.cxx will always +get built. If the component had the default bool +flavor then users would be able to disable the whole component, +and one less file would need to be built. However random number +generation is relatively simple, so the impact on eCos build times are +small. Furthermore by default the code has no dependencies on other +parts of the system, so compiling the code has no unexpected side +effects. Even if it was possible to disable the component, the +sensible default for most applications would still leave it enabled. +The net result is that the flavor none is probably +the most sensible one for this component. For other components the +default bool flavor or one of the other flavors +might be more appropriate. + + +Next consider option CYGSEM_LIBC_PER_THREAD_RAND +which can be used to get a per-thread random number seed, possibly +useful if the application needs a consistent sequence of random +numbers. In the absence of a &flavor; property this option will be +boolean, and the &default-value; property means that it is disabled by +default — reasonable since few applications need this +particular functionality, and it does impose a constraint on the rest +of the system. If the option is left disabled then no +#define will be generated, and if there were any +&compile; or similar properties these would not take effect. If the +option is enabled then a #define will be generated, +using the option's data part which is fixed at 1: + + +#define CYGSEM_LIBC_PER_THREAD_RAND 1 + + +The CYGSEM_LIBC_PER_THREAD_RAND option has a +&requires; constraint on +CYGVAR_KERNEL_THREADS_DATA. If the C library option +is enabled then the constraint should be satisfied, or else the +configuration contains a conflict. If the configuration does not +include the kernel package then +CYGVAR_KERNEL_THREADS_DATA will evaluate to +0 and the constraint is not satisfied. Similarly if +the option is inactive or disabled the constraint will not be +satisfied. + + +CYGNUM_LIBC_RAND_SEED and +CYGNUM_LIBC_RAND_TRACE_LEVEL both have the +data flavor, so they are always enabled and the +component framework will generate appropriate +#define's: + + +#define CYGNUM_LIBC_RAND_SEED 1 +#define CYGNUM_LIBC_RAND_SEED_1 +#define CYGNUM_LIBC_RAND_TRACE_LEVEL 0 +#define CYGNUM_LIBC_RAND_TRACE_LEVEL_0 + + +Neither option has a &compile; or similar property, but any such +properties would take effect. Any references to these options in &CDL; +expressions would evaluate to the data part, so a hypothetical +constraint of the form +{ requires CYGNUM_LIBC_RAND_SEED > 42 } +would not be satisfied with the default values. Both options use a +simple constant for the &default-value; expression. It would be +possible to use a more complicated expression, for example the default +for CYGNUM_LIBC_RAND_TRACE_LEVEL could be +determined from some global debugging option or from a debugging +option that applies to the C library as a whole. Both options also +have a &legal-values; constraint, which must be satisfied since the +options are active and enabled. + + + +The value 0 is legal for both +CYGNUM_LIBC_RAND_SEED and +CYGNUM_LIBC_RAND_TRACE_LEVEL, so in a &CDL; +expression there is no easy way of distinguishing between the options +being absent or having that particular value. This will be addressed +by future enhancements to the expression syntax. + + + + + + + + + + + + +Ordinary Expressions + + +Expressions in &CDL; follow a conventional syntax, for example: + + + default_value CYGGLO_CODESIZE > CYGGLO_SPEED + default_value { (CYG_HAL_STARTUP == "RAM" && + !CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS && + !CYGINT_HAL_USE_ROM_MONITOR_UNSUPPORTED && + !CYGSEM_HAL_POWERPC_COPY_VECTORS) ? 1 : 0 } + default_value { "\"/dev/ser0\"" } + + +However there is a complication in that the various arguments to a +&default-value; property will first get processed by a &Tcl; +interpreter, so special characters like quotes and square brackets may +get processed. Such problems can be avoided by enclosing non-trivial +expressions in braces, as in the second example above. The way +expression parsing actually works is as follows: + + + + +The &Tcl; interpreter splits the line or lines into a command and its +arguments. In the first &default-value; expression above the command +is default_value and there are three arguments, +CYGGLO_CODESIZE, > and +CYGGLO_SPEED. In the second and third examples +there is just one argument, courtesy of the braces. + + + + +Next option processing takes place, so any initial arguments that +begin with a hyphen will be interpreted as options. This can cause +problems if the expression involves a negative number, so the +special argument -- can be used to prevent option +processing on the subsequent arguments. + + + + +All of the arguments are now concatenated, with a single space in +between each one. Hence the following two expressions are equivalent, +even though they will have been processed differently up to this point. + + + default_value CYGGLO_CODESIZE > CYGGLO_SPEED + default_value {CYGGLO_CODESIZE > CYGGLO_SPEED} + + + + +The expression parsing code now has a single string to process. + + + + +&CDL; expressions consist of four types of element: references to +configuration options, constant strings, integers, and floating point +numbers. These are combined using a conventional set of operators: the +unary operators -, ~ and +!; the arithmetic operators +, +-, *, / and +%; the shift operators << +and >>; the comparison operators +==, !=, <, +<=, > and +>=; the bitwise operators +&, ^ and +|; the logical operators && and +||; the string concatenation operator +.; and the ternary conditional operator +A ? B : C. There is also support for +some less widely available operators for logical equivalence and +implication, and for a set of function-style operations. Bracketed +sub-expressions are supported, and the operators have the usual +precedence: + + + + + + + + + Priority + Operators + Category + + + + + 16 + references, constants + basic elements + + + 15 + f(a, b, c) + function calls + + + 14 + ~ + bitwise not + + + 14 + ! + logical not + + + 14 + - + arithmetic negation + + + 13 + * / % + multiplicative arithmetic + + + 12 + + - . + additive arithmetic and string concatenation + + + 11 + << >> + bitwise shifts + + + 10 + <= < > >= + inequality + + + 9 + == != + comparison + + + 8 + & + bitwise and + + + 7 + ^ + bitwise xor + + + 6 + | + bitwise or + + + 5 + && + logical and + + + 4 + || + logical or + + + 3 + xor, eqv + logical equivalance + + + 2 + implies + logical implication + + + 1 + ? : + conditional + + + + + + +Function calls have the usual format of a name, an opening bracket, +one or more arguments separated by commas, and a closing bracket. For +example: + + + requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, " -fno-rtti") } + + +Functions will differ in the number of arguments and may impose +restrictions on some or all of their arguments. For example it may be +necessary for the first argument to be a reference to a configuration +option. The available functions are described in . + + +The logical xor operator evaluates to true if +either the left hand side or the right hand side but not both evaluate +to true The logical eqv operator evaluates to true +if both the left and right hand sides evaluate to true, or if both +evaluate to false. The implies operator evaluates +to true either if the left hand side is false or if the right hand +side is true, in other words A implies B +has the same meaning as !A || B. An +example use would be: + + + requires { is_active(CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE) implies + (CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE >= (16 * 1024)) } + + +This constraint would be satisfied if either the support for a main +stack size is disabled, or if that stack is at least 16K. However if +such a stack were in use but was too small, a conflict would be raised. + + +A valid &CDL; identifier in an expression, for example +CYGGLO_SPEED, will be interpreted as a reference to +a configuration option by that name. The option does not have to be +loaded into the current configuration. When the component framework +evaluates the expression it will substitute in a suitable value that +depends on whether or not the option is loaded, active, and enabled. +The exact rules are described in . + + +A constant string is any sequence of characters enclosed in quotes. +Care has to be taken that these quotes are not stripped off by the +&Tcl; interpreter before the &CDL; expression parser sees them. +Consider the following: + + + default_value "RAM" + + +The quote marks will be stripped before the &CDL; expression parser +sees the data, so the expression will be interpreted as a reference to +a configuration option RAM. There is unlikely to be +such an option, so the actual default value will be +0. Careful use of braces or other &Tcl; quoting +mechanisms can be used to avoid such problems. + + +String constants consist of the data inside the quotes. If the data +itself needs to contain quote characters then appropriate quoting is +again necessary, for example: + + + default_value { "\"/dev/ser0\"" } + + +An integer constant consists of a sequence of digits, optionally +preceeded with the unary + or - +operators. As usual the sequence 0x or +0X can be used for hexadecimal data, and a leading +0 indicates octal data. Internally the component +framework uses 64-bit arithmetic for integer data. If a constant is +too large then double precision arithmetic will be used instead. +Traditional syntax is also used for double precision numbers, for +example 3.141592 or -3E6. + + +Of course this is not completely accurate: &CDL; is not a typed +language, all data is treated as if it were a string. For example the +following two lines are equivalent: + + + requires CYGNUM_UITRON_SEMAS > 10 + requires { CYGNUM_UITRON_SEMAS > "10" } + + +When an expression gets evaluated the operators will attempt +appropriate conversions. The > comparison +operator can be used on either integer or double precision numbers, so +it will begin by attempting a string to integer conversion of both +operands. If that fails it will attempt string to double conversions. +If that fails as well then the component framework will report a +conflict, an evaluation exception. If the conversions from string to +integer are successful then the result will be either the string +0 or the string 1, both of which +can be converted to integers or doubles as required. + + +It is worth noting that the expression +CYGNUM_UITRON_SEMAS >10 is not ambiguous. +&CDL; identifiers can never begin with a digit, so it is not possible +for 10 to be misinterpreted as a reference to an +identifier instead of as a string. + + +Of course the implementation is slightly different again. The &CDL; +language definition is such that all data is treated as if it were a +string, with conversions to integer, double or boolean as and when +required. The implementation is allowed to avoid conversions until +they are necessary. For example, given +CYGNUM_UITRON_SEMAS > 10 the +expression parsing code will perform an immediate conversion from +string to integer, storing the integer representation, and there is no +need for a conversion by the comparison operator when the expression +gets evaluated. Given +{ CYGNUM_UITRON_SEMAS > "10" } +the parsing code will store the string representation and a conversion +happens the first time the expression is evaluated. All of this is an +implementation detail, and does not affect the semantics of the +language. + + +Different operators have different requirements, for example the +bitwise or operator only makes sense if both operands have an integer +representation. For operators which can work with either integer or +double precision numbers, integer arithmetic will be preferred. + + +The following operators only accept integer operands: +unary ~ (bitwise not), the shift operators +<< and >>, and the +bitwise operators &, | and +^. + + +The following operators will attempt integer arithmetic first, then +double precision arithmetic: unary -, +the arithmetic operators +, -, +*, /, and %; +and the comparision operators <, +<=, > and +>=. + + +The equality == and inequality +!= operators will first attempt integer conversion +and comparison. If that fails then double precision will be attempted +(although arguably using these operators on double precision data is +not sensible). As a last resort string comparison will be used. + + +The operators !, && and +|| all work with boolean data. Any string that can +be converted to the integer 0 or the double +0.0 is treated as false, as is the empty string or +the constant string false. Anything else is +interpreted as true. The result is either 0 or +1. + + +The conditional operator ? : will interpret +its first operand as a boolean. It does not perform any processing on +the second or third operands. + + +In practice it is rarely necessary to worry about any of these +details. In nearly every case &CDL; expressions just work as expected, +and there is no need to understand the full details. + + + + +The current expression syntax does not meet all the needs of component +writers. Some future enhancements will definitely be made, others are +more controversial. The list includes the following: + + + + +An option's value is determined by several different factors: whether +or not it is loaded, whether or not it is active, whether or not it is +enabled, and the data part. Currently there is no way of querying +these individually. This is very significant in the context of options +with the bool or booldata +flavors, because there is no way of distinguishing between the option +being absent/inactive/disabled or it being enabled with a data field +of 0. There should be unary operators that allow +any of the factors to be checked. + + + + +Only the == and != operators can +be used for string data. More string-related facilities are needed. + + + + +An implies operator would be useful for many goal expression, where +A implies B is equivalent to +!A ||B. + + + + +Similarly there is inadequate support for lists. On occasion it would +be useful to write expressions involving say the list of implementors +of a given CDL interface, for example a sensible default value could +be the first implementor. Associated with this is a need for an +indirection operator. + + + + +Arguably extending the basic &CDL; expression syntax with lots of new +operators is unnecessary, instead expressions should just support +&Tcl; command substitution and then component writers could escape +into &Tcl; scripts for complicated operations. This has some major +disadvantages. First, the inference engine would no longer have any +sensible way of interpreting an expression to resolve a conflict. +Second, the component framework's value propagation code keeps track +of which options get referenced in which expressions and avoids +unnecessary re-evaluation of expressions; if expressions can involve +arbitrary &Tcl; code then there is no simple way to eliminate +unnecessary recalculations, with a potentially major impact on +performance. + + + + + + + +The current implementation of the component framework uses 64 bit +arithmetic on all host platforms. Although this is adequate for +current target architectures, it may cause problems in future. At some +stage it is likely that an arbitrary precision integer arithmetic +package will be used instead. + + + + + + + + + +Functions + + +CDL expressions can contain calls to a set of built-in functions +using the usual syntax, for example; + + + requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, "-fno-rtti") } + + +The available function calls are as follows: + + + + + + + + get_data(option) + + +This function can be used to obtain just the data part of a loaded +configuration option, ignoring other factors such as whether or not +the option is active and enabled. It takes a single argument which +should be the name of a configuration option. If the specified option +is not loaded in the current configuration then the function returns +0, otherwise it returns the data part. Typically this function will +only be used in conjunction with is_active and +is_enabled for fine-grained control over the +various factors that make up an option's value. + + + + + + + + + is_active(option) + + +This function can be used to determine whether or not a particular +configuration option is active. It takes a single argument which +should be the name of an option, and returns a boolean. If the +specified option is not loaded then the function will return false. +Otherwise it will consider the state of the option's parents and +evaluate any &active-if; properties, and return the option's current +active state. A typical use might be: + + + requires { is_active(CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE) implies + (CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE >= (16 * 1024)) } + + +In other words either the specified configuration option must be +inactive, for example because the current application does not use +any related C library or POSIX functionality, or the stack size must +be at least 16K. + + +The configuration system's inference engine can attempt to satisfy +constraints involving is_active in various +different ways, for example by enabling or disabling parent +components, or by examining &active-if; properties and manipulating +terms in the associated expressions. + + + + + + + + + is_enabled(option) + + +This function can be used to determine whether or not a particular +configuration option is enabled. It takes a single argument which +should be the name of an option, and returns a boolean. If the +specified option is not loaded then the function will return false. +Otherwise it will return the current boolean part of the option's +value. The option's active or inactive state is ignored. Typically +this function will be used in conjunction with +is_active and possibly +get_data to provide fine-grained control over the +various factors that make up an option's value. + + + + + + + + + is_loaded(option) + + +This function can be used to determine whether or not a particular +configuration option is loaded. It takes a single argument which +should be the name of an option, and returns a boolean. If the +argument is a package then the is_loaded function +provides little or no extra information, for example the following two +constraints are usually equivalent: + + + requires { CYGPKG_KERNEL } + requires { is_loaded(CYGPKG_KERNEL) } + + +However if the specified package is loaded but re-parented below a +disabled component, or inactive as a result of an &active-if; +property, then the first constraint would not be satisfied but the +second constraint would. In other words the +is_loaded makes it possible to consider in +isolation one of the factors that are considered when CDL expressions +are evaluated. + + +The configuration system's inference engine will not automatically +load or unload packages to satisfy is_loaded +constraints. + + + + + + + + + is_substr(haystack, needle) + + +This can be used to check whether or not a particular string is +present in another string. It is used mainly for manipulating compiler +flags. The function takes two arguments, both of which can be +arbitrary expressions, and returns a boolean. + + +is_substr has some understanding of word +boundaries. If the second argument starts with a space character then +that will match either a real space or the start of the string. +Similarly if the second argument ends with a space character then that +will match a real space or the end of the string. For example, all of +the following conditions are satisfied: + + + is_substr("abracadabra", "abra") + is_substr("abracadabra", " abra") + is_substr("hocus pocus", " pocus") + is_substr("abracadabra", "abra ") + + +The first is an exact match. The second is a match because the leading +space matches the start of the string. The third is an exact match, +with the leading space matching an actual space. The fourth is a match +because the trailing space matches the end of the string. However, the +following condition is not satisfied. + + + is_substr("abracadabra", " abra ") + + +This fails to match at the start of the string because the trailing +space is not matched by either a real space or the end of the string. +Similarly it fails to match at the end of the string. + + +If a constraint involving is_substr is not +satisfied and the first argument is a reference to a configuration +option, the inference engine will attempt to modify that option's +value. This can be achieved either by appending the second argument to +the current value, or by removing all occurrences of that argument +from the current value. + + + requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, " -fno-rtti ") } + requires { is_substr(CYGBLD_GLOBAL_CFLAGS, " -frtti ") } + + +When data is removed the leading and trailing spaces will be left. For +example, given an initial value of +<CYGBLD_GLOBAL_CFLAGS of +-g -fno-rtti -O2 the result will be +-g  -O2 rather than -g-O2. + + +If exact matches are needed, the function +is_xsubstr can be used instead. + + + + + + + + + is_xsubstr(haystack, needle) + + +This function checks whether or not the pattern string is an exact +substring of the string being searched. It is similar to +is_substr but uses exact matching only. In other +words, leading or trailing spaces have to match exactly and will not +match the beginning or end of the string being searched. The function +takes two arguments, both of which can be arbitrary expressions, and +returns a boolean. The difference between +is_substr and is_xsubstr is +illustrated by the following examples: + + + cdl_option MAGIC { + flavor data + default_value { "abracadabra" } + } + … + requires { is_substr(MAGIC, " abra") } + requires { is_xsubstr(MAGIC, " abra") } + + +The first goal will be satisfied because the leading space in the +pattern matches the beginning of the string. The second goal will not +be satisfied initialy because there is no exact match, so the +inference engine is likely to update the value of +MAGIC to abracadabra abra which +does give an exact match. + + + + + + + + + version_cmp(A, B) + + +This function is used primarily to check that a sufficiently recent +version of some other package +is being used. It takes two arguments, both of which can be arbitrary +expressions. In practice usually one of the arguments will be a +reference to a package and the other will be a constant version +string. The return value is -1 if the first argument is a more recent +version then the second, 0 if the two arguments correspond to +identical versions, and 1 if the first argument is an older version. +For example the following constraint can be used to indicate that the +current package depends on kernel functionality that only became +available in version 1.3: + + + requires { version_cmp(CYGPKG_KERNEL, "v1.3") <= 0 } + + + + + + + + + + +At this time it is not possible to define new functions inside a CDL +script. Instead functions can only be added at the C++ level, usually +by extending libcdl itself. This is partly because there is more to +CDL functions than simple evaluation: associated with most functions +is support for the inference engine, so that if a constraint involving +a function is not currently satisfied the system may be able to find a +solution automatically. + + + + + + + + + +Goal Expressions + + +The arguments to certain properties, notably &requires; and +&active-if;, constitute a goal expression. As with an ordinary +expression, all of the arguments get combined and then the expression +parser takes over. The same care has to be taken with constant strings +and anything else that may get processed by the Tcl interpreter, so +often a goal expression is enclosed entirely in braces and the +expression parsing code sees just a single argument. + + +A goal expression is basically just a sequence of ordinary +expressions, for example: + + + requires { CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS + !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT + !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT } + + +This consists of three separate expressions, all of which should +evaluate to a non-zero result. The same expression could be written +as: + + + requires { CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS && + !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT && + !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT } + + +Alternatively the following would have much the same effect: + + + requires CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS + requires !CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT + requires !CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT + + +Selecting between these alternatives is largely a stylistic choice. +The first is slightly more concise than the others. The second is more +likely to appeal to mathematical purists. The third is more amenable +to cutting and pasting. + + +The result of evaluating a goal expression is a boolean. If any part +of the goal expression evaluates to the integer 0 +or an equivalent string then the result is false, otherwise it is +true. + + +The term “goal expression” relates to the component +framework's inference engine: it is a description of a goal that +should be satisfied for a conflict-free configuration. If a &requires; +constraint is not satisfied then the inference engine will examine the +goal expression: if there is some way of changing the configuration +that does not introduce new conflicts and that will cause the goal +expression to evaluate to true, the conflict can be resolved. + + +The inference engine works with one conflict and hence one goal +expression at a time. This means that there can be slightly different +behavior if a constraint is specified using a single &requires; +property or several different ones. Given the above example, suppose +that none of the three conditions are satisfied. If a single goal +expression is used then the inference engine might be able to satisfy +only two of the three parts, but since the conflict as a whole cannot +be resolved no part of the solution will be applied. Instead the user +will have to resolve the entire conflict. If three separate goal +expressions are used then the inference engine might well find +solutions to two of them, leaving less work for the user. On the other +hand, if a single goal expression is used then the inference engine +has a bit more information to work with, and it might well find a +solution to the entire conflict where it would be unable to find +separate solutions for the three parts. Things can get very +complicated, and in general component writers should not worry about +the subtleties of the inference engine and how to manipulate its +behavior. + + +It is possible to write ambiguous goal expressions, for example: + + + requires CYGNUM_LIBC_RAND_SEED -CYGNUM_LIBC_RAND_TRACE_LEVEL > 5 + + +This could be parsed in two ways: + + + requires ((CYGNUM_LIBC_RAND_SEED - CYGNUM_LIBC_RAND_TRACE_LEVEL) > 5) + requires CYGNUM_LIBC_RAND_SEED && ((-CYGNUM_LIBC_RAND_TRACE_LEVEL) > 5) + + +The goal expression parsing code will always use the largest ordinary +expression for each goal, so the first interpretation will be used. +In such cases it is a good idea to use brackets and avoid possible +confusion. + + + + + + + + +List Expressions + + +The arguments to the &legal-values; property constitute a goal +expression. As with an ordinary and goal expressions, all of the +arguments get combined and then the expression parser takes over. The +same care has to be taken with constant strings and anything else that +may get processed by the Tcl interpreter, so often a list expression +is enclosed entirely in braces and the expression parsing code sees +just a single argument. + + +Most list expressions take one of two forms: + + + legal_values <expr1> <expr2> <expr3> ... + legal_values <expr1> to <expr2> + + +expr1, expr2 and so on are +ordinary expressions. Often these will be constants or references to +calculated options in the architectural HAL package, but it is +possible to use arbitrary expressions when necessary. The first syntax +indicates a list of possible values, which need not be numerical. The +second syntax indicates a numerical range: both sides of the +to must evaluate to a numerical value; if either +side involves a floating point number then any floating point number +in that range is legal; otherwise only integer values are legal; +ranges are inclusive, so 4 is a valid value given a +list expression 1 to ; if one or both +sides of the to does not evaluate to a numerical +value then this will result in a run-time conflict. The following +examples illustrate these possibilities: + + + legal_values { "red" "green" "blue" } + legal_values 1 2 4 8 16 + legal_values 1 to CYGARC_MAXINT + legal_values 1.0 to 2.0 + + +It is possible to combine the two syntaxes, for example: + + + legal_values 1 2 4 to CYGARC_MAXINT -1024 -20.0 to -10 + + +This indicates three legal values 1, +2 and -1024, one +integer range 4 to CYGARC_MAXINT, and one +floating point range -20.0 to -10.0. In +practice such list expressions are rarely useful. + + +The identifier to is not reserved, so it is +possible to have a configuration option with that name (although it +violates every naming convention). Using that option in a list +expression may however give unexpected results. + + +The graphical configuration tool uses the &legal-values; list +expression to determine how best to let users manipulate the option's +value. Different widgets will be appropriate for different lists, so +{ "red" "green" "blue" } might +involve a pull-down option menu, and +1 to 16 could involve a spinner. The +exact way in which &legal-values; lists get mapped on to GUI widgets +is not defined and is subject to change at any time. + + +As with goal expressions, list expressions can be ambiguous. Consider +the following hypothetical example: + + + legal_values CYGNUM_LIBC_RAND_SEED -CYGNUM_LIBC_RAND_TRACE_LEVEL + + +This could be parsed in two ways: + + + legal_values (CYGNUM_LIBC_RAND_SEED - CYGNUM_LIBC_RAND_TRACE_LEVEL) + legal_values (CYGNUM_LIBC_RAND_SEED) (-CYGNUM_LIBC_RAND_TRACE_LEVEL) + + +Both are legal. The list expression parsing code will always use the +largest ordinary expression for each element, so the first +interpretation will be used. In cases like this it is a good idea to +use brackets and avoid possible confusion. + + + + + + + + + + + + + +Interfaces + + +For many configurability requirements, options provide sufficient +expressive power. However there are times when a higher level of +abstraction is appropriate. As an example, suppose that some package +relies on the presence of code that implements the standard kernel +scheduling interface. However the requirement is no more stringent +than this, so the constraint can be satisfied by the mlqueue +scheduler, the bitmap scheduler, or any additional schedulers that may +get implemented in future. A first attempt at expressing the +dependency might be: + + + requires CYGSEM_KERNEL_SCHED_MLQUEUE || CYGSEM_KERNEL_SCHED_BITMAP + + +This constraint will work with the current release, but it is limited. +Suppose there is a new release of the kernel which adds another +scheduler such as a deadline scheduler, or suppose that there is a new +third party package which adds such a scheduler. The package +containing the limited constraint would now have to be updated and +another release made, with possible knock-on effects. + + +&CDL; interfaces provide an abstraction mechanism: constraints can be +expressed in terms of an abstract concept, for example +“scheduler”, rather than specific implementations such as +CYGSEM_KERNEL_SCHED_MLQUEUE and +CYGSEM_KERNEL_SCHED_BITMAP. Basically an interface +is a calculated configuration option: + + +cdl_interface CYGINT_KERNEL_SCHEDULER { + display "Number of schedulers in this configuration" + … +} + + +The individual schedulers can then implement this interface: + + +cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE { + display "Multi-level queue scheduler" + default_value 1 + implements CYGINT_KERNEL_SCHEDULER + … +} + +cdl_option CYGSEM_KERNEL_SCHED_BITMAP { + display "Bitmap scheduler" + default_value 0 + implements CYGINT_KERNEL_SCHEDULER + … +} + + +Future schedulers can also implement this interface. The value of an +interface, for the purposes of expression evaluation, is the number of +active and enabled options which implement this interface. Packages +which rely on the presence of a scheduler can impose constraints such +as: + + + requires CYGINT_KERNEL_SCHEDULER + + +If none of the schedulers are enabled, or if the kernel package is not +loaded, then CYGINT_KERNEL_SCHEDULER will evaluate +to 0. If at least one scheduler is active and +enabled then the constraint will be satisfied. + + +Because interfaces have a calculated value determined by the +implementors, the &default-value; and &calculated; properties are not +applicable and should not appear in the body of a &cdl-interface; +command. Interfaces have the data flavor by +default, but the bool and +booldata flavors may be specified instead. A +bool interface is disabled if there are no active +and enabled implementors, otherwise it is enabled. A +booldata interface is disabled if there are no +active and enabled implementors, otherwise it is enabled and has a +value corresponding to the number of these implementors. Other +properties such as &requires; and &compile; can be used as normal. + + +Some component writers will not want to use interfaces in this way. +The reasoning is that their code will only have been tested with the +existing schedulers, so the &requires; constraint needs to be +expressed in terms of those schedulers; it is possible that the +component will still work with a new scheduler, but there are no +guarantees. Other component writers may take a more optimistic view +and assume that their code will work with any scheduler until proven +otherwise. It is up to individual component writers to decide which +approach is most appropriate in any given case. + + +One common use for interfaces is to describe the hardware +functionality provided by a given target. For example the &CDL; +scripts for a TCP/IP package might want to know whether or not the +target hardware has an ethernet interface. Generally it is not +necessary for the TCP/IP stack to know exactly which ethernet hardware +is present, since there should be a device driver which implements the +appropriate functionality. In &CDL; terms the device drivers should +implement an interface CYGHWR_NET_DRIVERS, and the +&CDL; scripts for the TCP/IP stack can use this in appropriate +expressions. + + + +Using the term interface for this concept is +sometimes confusing, since the term has various other meanings as +well. In practice, it is often correct. If there is a configuration +option that implements a given &CDL; interface, then usually this +option will enable some code that provides a particular interface at +the C or C++ level. For example an ethernet device driver implements +the &CDL; interface CYGHWR_NET_DRIVERS, and also +implements a set of C functions that can be used by the TCP/IP stack. +Similarly CYGSEM_KERNEL_SCHED_MLQUEUE implements +the &CDL; interface CYGINT_KERNEL_SCHEDULER and +also provides the appropriate scheduling functions. + + + + + + + + + +Updating the <database>ecos.db</database> database + + +The current implementation of the component framework requires that +all packages be present in a single component repository and listed in +that repository's ecos.db database. This is not +generally a problem for application developers who can consider the +component repository a read-only resource, except when adding or +removing packages via the administration tool. However it means that +component writers need to do their development work inside a +component repository as well, and update the database with details of +their new package or packages. Future enhancements to the component +framework may allow new components to be developed outside a +repository. + + +Like most files related to the component framework, the +ecos.db database is actually a &Tcl; script. +Typical package entries would look like this: + + +package CYGPKG_LIBC { + alias { "C library" libc clib clibrary } + directory language/c/libc + script libc.cdl + description " +This package enables compatibility with the ISO C standard - ISO/IEC +9899:1990. This allows the user application to use well known standard +C library functions, and in eCos starts a thread to invoke the user +function main()" +} + +package CYGPKG_IO_PCI { + alias { "PCI configuration library" io_pci } + directory io/pci + script io_pci.cdl + hardware + description " + This package contains the PCI configuration library." +} + + +The package command takes two arguments, a name and +a body. The name must be the same as in the &cdl-package; command in +the package's top-level &CDL; script. The body can contain the +following five commands: alias, +directory, script, +hardware and description. + + + + +alias + + +Each package should have one or more aliases. The first alias is +typically used when listing the known packages, because a string like +C library is a bit easier to read and +understand than CYGPKG_LIBC. The other aliases are +not used for output, but are accepted on input. For example the +ecosconfig command-line +tool will accept add libc as an option, as well +as add CYGPKG_LIBC. + + + + + +directory + + +This is used to specify the location of the package relative to the +root of the component repository. It should be noted that in the +current component framework this location cannot be changed in +subsequent releases of the package: if for some reason it is desirable +to install a new release elsewhere in the repository, all the old +versions must first be uninstalled; the database cannot hold two +separate locations for one package. + + + + + +script + + +The script command specifies the location of the +package's top-level &CDL; script, in other words the one containing the +&cdl-package; definition. If the package follows the directory layout conventions then +this script will be in the cdl +sub-directory, otherwise it will be relative to the package's top-level +directory. Again once a release has been made this file should not +change in later releases. In practice the top-level script is generally +named after the package itself, so changing its name is unlikely to be +useful. + + + + + +hardware + + +Packages which are tied to specific hardware, for example device +drivers and HAL packages, should indicate this in both the +&cdl-package; command of the &CDL; script and in the database entry. + + + + + +description + + +This should give a brief description of the package. Typically the +text for the &description; property in the &cdl-package; command will +be re-used. + + + + + + + +Most of the information in the ecos.db file could +be obtained by a relatively simple utility. This would be passed a +single argument identifying a package's top-level &CDL; script. The +directory path relative to the component repository root could be +determined from the filename. The name, description +and hardware fields could be obtained from the +script's &cdl-package; command. The &display; property would supply +the first alias, additional aliases could be obtained by extending the +syntax of that property or by other means. Something along these lines +may be provided by a future release of the component framework. + + + +Currently the ecos.db database also holds +information about the various targets. When porting to a new target it +will be necessary to add information about the target to the database, +as well as the details of the new platform HAL package and any related +packages. + + + + + + + \ No newline at end of file diff --git a/host/libcdl/doc/main.sgml b/host/libcdl/doc/main.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/main.sgml @@ -0,0 +1,106 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +eCos"> +CDL"> +CVS"> +Tcl"> + +cdl_option"> +cdl_component"> +cdl_package"> +cdl_interface"> +active_if"> +calculated"> +compile"> +default_value"> +define"> +define_format"> +define_header"> +define_proc"> +description"> +display"> +doc"> +flavor"> +hardware"> +if_define"> +implements"> +include_dir"> +include_files"> +legal_values"> +library"> +make"> +make_object"> +no_define"> +parent"> +requires"> +script"> +]> + + + The &eCos; Component Writer's Guide + + The &eCos; Component Writer's Guide + + BartVeer + JohnDallaway + + 2001 + 20002001 + Red Hat Inc. + + + + &chap1; + &chap2; + &chap3; + &chap4; + &chap5; + &chap6; + + diff --git a/host/libcdl/doc/makefile b/host/libcdl/doc/makefile new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/makefile @@ -0,0 +1,45 @@ +#============================================================================= +# +# makefile +# +# For building the Component Writer's Guide +# +#============================================================================= +#####ECOSHOSTGPLCOPYRIGHTBEGIN#### +# ------------------------------------------- +# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +# +# This file is part of the eCos host tools. +# +# This program is free software; you can redistribute it and/or modify it +# under the terms of the GNU General Public License as published by the Free +# Software Foundation; either version 2 of the License, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, but WITHOUT +# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +# more details. +# +# You should have received a copy of the GNU General Public License along with +# this program; if not, write to the Free Software Foundation, Inc., +# 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +# +# ------------------------------------------- +#####ECOSHOSTGPLCOPYRIGHTEND#### +#============================================================================= +#####DESCRIPTIONBEGIN#### +# +# Author(s): bartv +# Date: 2001-04-19 +#####DESCRIPTIONEND#### +#============================================================================= + +TOPLEVEL := ../../../packages +MAIN_SGML := main.sgml +MAIN_HTML := cdl-guide.html +MAIN_PDF := main.pdf +OTHER_SGML := concepts.sgml package.sgml language.sgml reference.sgml build.sgml advanced.sgml +PICTURES := repo version package + +include $(TOPLEVEL)/pkgconf/rules.doc diff --git a/host/libcdl/doc/package.fig b/host/libcdl/doc/package.fig new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/package.fig @@ -0,0 +1,32 @@ +#FIG 3.2 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 900 1200 5400 1200 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 900 1200 900 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1800 1200 1800 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 2700 1200 2700 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3600 1200 3600 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 4500 1200 4500 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 5400 1200 5400 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3150 600 3150 1200 +4 0 0 100 0 0 14 0.0000 4 195 1020 225 2100 ChangeLog\001 +4 0 0 100 0 0 14 0.0000 4 150 255 1650 2100 cdl\001 +4 0 0 100 0 0 14 0.0000 4 135 405 5175 2100 tests\001 +4 0 0 100 0 0 14 0.0000 4 105 270 4350 2100 src\001 +4 0 0 100 0 0 14 0.0000 4 150 615 3300 2100 include\001 +4 0 0 100 0 0 14 0.0000 4 150 315 2550 2100 doc\001 +4 0 0 100 0 0 14 0.0000 4 195 975 2700 450 \001 diff --git a/host/libcdl/doc/package.sgml b/host/libcdl/doc/package.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/package.sgml @@ -0,0 +1,1276 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Package Organization + + + + +For a package to be usable in the &eCos; component framework it must +conform to certain rules imposed by that framework. Packages must be +distributed in a form that is understood by the component repository +administration tool. There must be a top-level &CDL; script which +describes the package to the component framework. There are certain +limitations related to how a package gets built, so that the package +can still be used in a variety of host environments. In addition to +these rules, the component framework provides a number of guidelines. +Packages do not have to conform to the guidelines, but sticking to +them can simplify certain operations. + + +This chapter deals with the general organization of a package, for +example how to distinguish between private and exported header files. + describes the &CDL; language. + details the build process. + + + + + + +Packages and the Component Repository + + +All &eCos; installations include a component repository. This is a +directory structure for all installed packages. The component +framework comes with an administration tool that allows new packages +or new versions of a package to be installed, old packages to be +removed, and so on. The component repository includes a simple +database, maintained by the administration tool, which contains +details of the various packages. + + + + + + + + + + + + + + +Each package has its own little directory hierarchy within the +component repository. Keeping several packages in a single directory +is illegal. The error, infra and kernel packages all live at the +top-level of the repository. For other types of packages there are +some pre-defined directories: compat is used for compatibility +packages, which implement other interfaces such as &uITRON; or POSIX +using native &eCos; calls; hal +is used for packages that port &eCos; to different architectures or +platforms, and this directory is further organized on a +per-architecture basis; io is +intended for device drivers; language is used for language support +libraries, for example the C library. There are no strict rules +defining where new packages should get installed. Obviously if an +existing top-level directory such as compat is applicable then the new package +should go in there. If a new category is desirable then it is possible +to create a new sub-directory in the component repository. For +example, an organization planning to release a number of &eCos; +packages may want them all to appear below a sub-directory +corresponding to the organization's name — in the hope that +the name will not change too often. It is possible to add new packages +directly to the top-level of the component repository, but this should +be avoided. + + + +The ecos.db file holds the component repository +database and is managed by the administration tool. The various +configuration tools read in this file when they start-up to obtain +information about the various packages that have been installed. When +developing a new package it is necessary to add some information to +the file, as described in . The +templates directory holds +various configuration templates. + + + + +Earlier releases of &eCos; came with two separate files, +targets and packages. The +ecos.db database replaces both of these. + + + + + +The current ecos.db database does not yet provide +all of the information needed by the component framework. Its format +is subject to change in future releases, and the file may be replaced +completely if necessary. There are a number of other likely future +developments related to the component repository and the database. The +way targets are described is subject to change. Sometimes it is +desirable for component writers to do their initial development in a +directory outside the component repository, but there is no specific +support in the framework for that yet. + + + + + + + + + +Package Versioning + +Below each package directory there can be one or more version +sub-directories, named after the versions. This is a requirement of +the component framework: it must be possible for users to install +multiple versions of a package and select which one to use for any +given application. This has a number of advantages to users: most +importantly it allows a single component repository to be shared +between multiple users and multiple projects, as required; also it +facilitates experiments, for example it is relatively easy to try out +the latest version of some package and see if it makes any difference. +There is a potential disadvantage in terms of disk space. However +since &eCos; packages generally consist of source code intended for +small embedded systems, and given typical modern disk sizes, keeping a +number of different versions of a package installed will usually be +acceptable. The administration tool can be used to remove versions +that are no longer required. + + + + + + + + + + + + + + +The version current is special. Typically it +corresponds to the very latest version of the sources, obtained by +anonymous &CVS;. These sources may change frequently, unlike full +releases which do not change (or only when patches are produced). +Component writers may also want to work on the +current version. + + +All other subdirectories of a package correspond to specific releases +of that package. The component framework allows users to select the +particular version of a package they want to use, but by default the +most recent one will be used. This requires some rules for ordering +version numbers, a difficult task because of the wide variety of ways +in which versions can be identified. + + + + + +The version current is always considered to be +the most recent version. + + + + +If the first character of both strings are either v +or V, these are skipped because it makes little +sense to enforce case sensitivity here. Potentially this could result +in ambiguity if there are two version directories +V1.0 and v1.0, but this will +match the confusion experienced by any users of such a package. +However if two subsequent releases are called V1.0 +and v1.1, e.g. because of a minor mix-up when +making the distribution file, then the case difference is ignored. + + + + + +Next the two version strings are compared one character at a time. +If both strings are currently at a digit then a string to number +conversion takes place, and the resulting numbers are compared. +For example v10 is a more recent release than +v2. If the two numbers are the same then processing +continues, so for v2b and v2c +the version comparison code would move on to b and +c. + + + + + +The characters dot ., hyphen - +and underscore _ are treated as equivalent +separators, so if one release goes out as v1_1 and +the next goes out as v1.2 the separator has no +effect. + + + + + +If neither string has yet terminated but the characters are different, +ASCII comparison is used. For example V1.1b is +more recent than v1.1alpha. + + + + + +If one version string terminates before the other, the current +character determines which is the more recent. If the other string is +currently at a separator character, for example +v1.3.1 and v1.3, then the former +is assumed to be a minor release and hence more recent than the +latter. If the other string is not at a separator character, for +example v1.3beta, then it is treated as an +experimental version of the v1.3 release and hence +older. + + + + + +There is no special processing of dates, so with two versions +ss-20000316 and ss-20001111 +the numerical values 20001111 and +20000316 determine the result: larger values are +more recent. It is suggested that the full year be used in such cases +rather than a shorthand like 00, to avoid +Y2100 problems. + + + + + +There is no limit on how many levels of versioning are used, so +there could in theory be a v3.1.4.1.5.9.2.7 release +of a package. However this is unlikely to be of benefit to typical +users of a package. + + + + + + +The version comparison rules of the component framework may not be +suitable for every version numbering scheme in existence, but they +should cope with many common cases. + + + + +There are some issues still to be resolved before it is possible to +combine the current sources available via +anonymous &CVS and full releases of &eCos; and additional packages in +a single component repository. The first problem relates to the +ecos.db database: if a new package is added via +the CVS repository then this requires a database update, but the +administration tool is bypassed. The second problem arises if an +organization chooses to place its component repository under source +code control using &CVS;, in which case different directories will +belong to different &CVS; servers. These issues will be addressed in a +future release. + + + + + + + + + + + +Package Contents and Layout + +A typical package contains the following: + + + + +Some number of source files which will end up in a library. The +application code will be linked with this library to produce an +executable. Some source files may serve other purposes, for example to +provide a linker script. + + + + +Exported header files which define the interface provided by the +package. + + + + +On-line documentation, for example reference pages for each exported +function. + + + + +Some number of test cases, shipped in source format, allowing users to +check that the package is working as expected on their particular +hardware and in their specific configuration. + + + + +One or more &CDL; scripts describing the package to the configuration +system. + + + + +It is also conventional to have a per-package +ChangeLog file used to keep track of changes to +that package. This is especially valuable to end users of the package +who may not have convenient access to the source code control system +used to manage the master copy of the package, and hence cannot find +out easily what has changed. Often it can be very useful to the main +developers as well. + + +Any given packages need not contain all of these. It is compulsory to +have at least one &CDL; script describing the package, otherwise the +component framework would be unable to process it. Some packages may +not have any source code: it is possible to have a package that merely +defines a common interface which can then be implemented by several +other packages, especially in the context of device drivers; however +it is still common to have some code in such packages to avoid +replicating shareable code in all of the implementation packages. +Similarly it is possible to have a package with no exported header +files, just source code that implements an existing interface: for +example an ethernet device driver might just implement a standard +interface and not provide any additional functionality. Packages do +not need to come with any on-line documentation, although this may +affect how many people will want to use the package. Much the same +applies to per-package test cases. + + + +The component framework has a recommended per-package directory layout +which splits the package contents on a functional basis: + + + + + + + + + + + + + + +For example, if a package has an include sub-directory then the component +framework will assume that all header files in and below that +directory are exported header files and will do the right thing at +build time. Similarly if there is &doc; property indicating the +location of on-line documentation then the component framework will +first look in the doc +sub-directory. + + + +This directory layout is just a guideline, it is not enforced by the +component framework. For simple packages it often makes more sense to +have all of the files in just one directory. For example a package +could just contain the files hello.cxx, +hello.h, hello.html and +hello.cdl. By default +hello.h will be treated as an exported header +file, although this can be overridden with the &include-files; property. Assuming +there is a &doc; property referring to hello.html +and there is no doc +sub-directory then the tools will search for this file relative to the +package's top-level and everything will just work. Much the same +applies to hello.cxx and +hello.cdl. + + + + +Older versions of the &eCos; build system only supported packages that +followed the directory structure exactly. Hence certain core packages +such as error implement the full directory +structure, even though that is a particularly simple package and the +full directory structure is inappropriate. Component writers can +decide for themselves whether or not the directory structure +guidelines are appropriate for their package. + + + + + + + +Outline of the Build Process + +The full build process is described in , but +a summary is appropriate here. A build involves three directory +structures: + + + + + +The component repository. This is where all the package source code is +held, along with &CDL; scripts, documentation, and so on. For build +purposes a component repository is read-only. Application developers +will only modify the component repository when installing or removing +packages, via the administration tool. Component writers will +typically work on just one package in the component repository. + + + + +The build tree. Each configuration has its own build tree, which can +be regenerated at any time using the configuration's +ecos.ecc savefile. The build tree contains only +intermediate files, primarily object files. Once a build is complete +the build tree contains no information that is useful for application +development and can be wiped, although this would slow down any +rebuilds following changes to the configuration. + + + + +The install tree. This is populated during a build, and contains all +the files relevant to application development. There will be a +lib sub-directory which +typically contains libtarget.a, a linker script, +start-up code, and so on. There will also be an include sub-directory containing all the +header files exported by the various packages. There will also be a +include/pkgconf sub-directory +containing various configuration header files with +#define's for the options. Typically the install +tree is created within the build tree, but this is not a requirement. + + + + + +The build process involves the following steps: + + + + +Given a configuration, the component framework is responsible for +creating all the directories in the build and install trees. If these +trees already exist then the component framework is responsible for +any clean-ups that may be necessary, for example if a package has been +removed then all related files should be expunged from the build and +install trees. The configuration header files will be generated at +this time. Depending on the host environment, the component framework +will also generate makefiles or some other way of building the various +packages. Every time the configuration is modified this step needs to +be repeated, to ensure that all option consequences take effect. Care +is taken that this will not result in unnecessary rebuilds. + + + +At present this step needs to be invoked manually. In a future version +the generated makefile may if desired perform this step automatically, +using a dependency on the ecos.ecc savefile. + + + + + +The first step in an actual build is to make sure that the install +tree contains all exported header files. All compilations will use +the install tree's include +directory as one of the places to search for header files. + + + + +All source files relevant to the current configuration get compiled. +This involves a set of compiler flags initialized on a per-target +basis, with each package being able to modify these flags, and with +the ability for the user to override the flags as well. Care has to be +taken here to avoid inappropriate target-dependencies in packages that +are intended to be portable. The component framework has built-in +knowledge of how to handle C, C++ and assembler source files — +other languages may be added in future, as and when necessary. The +&compile; property is used to +list the files that should get compiled. All object files end up in +the build tree. + + + + +Once all the object files have been built they are collected into a +library, typically libtarget.a, which can then be +linked with application code. The library is generated in the install +tree. + + + + +The component framework provides support for custom build steps, using +the &make-object; and +&make; properties. The results of +these custom build steps can either be object files that should end up +in a library, or other files such as a linker script. It is possible +to control the order in which these custom build steps take place, for +example it is possible to run a particular build step before any of +the compilations happen. + + + + + + + + + + +Configurable Source Code + +All packages should be totally portable to all target hardware (with +the obvious exceptions of HAL and device driver packages). They should +also be totally bug-free, require the absolute minimum amount of code +and data space, be so efficient that cpu time usage is negligible, and +provide lots of configuration options so that application developers +have full control over the behavior. The configuration options are +optional only if a package can meet the requirements of every +potential application without any overheads. It is not the purpose of +this guide to explain how to achieve all of these requirements. + + +The &eCos; component framework does have some important implications +for the source code: compiler flag dependencies; package interfaces +vs. implementations; and how configuration options affect source code. + + + +Compiler Flag Dependencies + +Wherever possible component writers should avoid dependencies on +particular compiler flags. Any such dependencies are likely to impact +portability. For example, if one package needs to be built in +big-endian mode and another package needs to be built in little-endian +mode then usually it will not be possible for application developers +to use both packages at the same time; in addition the application +developer is no longer given a choice in the matter. It is far better +for the package source code to adapt the endianness at compile-time, +or possibly at run-time although that will involve code-size +overheads. + + + +A related issue is that the current support for handling compiler +flags in the component framework is still limited and incapable of +handling flags at a very fine-grain. The support is likely to be +enhanced in future versions of the framework, but there are +non-trivial problems to be resolved. + + + + + +Package Interfaces and Implementations + +The component framework provides encapsulation at the package level. A +package A has no way of accessing the +implementation details of another package B at +compile-time. In particular, if there is a private header file +somewhere in a package's src +sub-directory then this header file is completely invisible to other +packages. Any attempts to cheat by using relative pathnames beginning +with ../.. are generally doomed +to failure because of the presence of package version directories. +There are two ways in which one package can affect another: by means +of the exported header files, which define a public interface; or via +the &CDL; scripts. + + +This encapsulation is a deliberate aspect of the overall &eCos; +component framework design. In most cases it does not cause any +problems for component writers. In some cases enforcing a clean +separation between interface and implementation details can improve +the code. Also it reduces problems when a package gets upgraded: +component writers are free to do pretty much anything on the +implementation side, including renaming every single source file; care +has to be taken only with the exported header files and with the &CDL; +data, because those have the potential of impacting other packages. +Application code is similarly unable to access package implementation +details, only the exported interface. + + +Very occasionally the inability of one package to see implementation +details of another does cause problems. One example occurs in HAL +packages, where it may be desirable for the architectural, variant and +platform HAL's to share some information that should not be visible to +other packages or to application code. This may be addressed in the +future by introducing the concept of friend +packages, just as a C++ class can have friend +functions and classes which are allowed special access to a class +internals. It is not yet clear whether such cases are sufficiently +frequent to warrant introducing such a facility. + + + + +Source Code and Configuration Options + +Configurability usually involves source code that needs to implement +different behavior depending on the settings of configuration +options. It is possible to write packages where the only consequence +associated with various configuration options is to control what gets +built, but this approach is limited and does not allow for +fine-grained configurability. There are three main ways in which +options could affect source code at build time: + + + + + +The component code can be passed through a suitable preprocessor, +either an existing one such as m4 or a new one specially designed with +configurability in mind. The original sources would reside in the +component repository and the processed sources would reside in the +build tree. These processed sources can then be compiled in the usual +way. + + +This approach has two main advantages. First, it is independent from +the programming language used to code the components, provided +reasonable precautions are taken to avoid syntax clashes between +preprocessor statements and actual code. This would make it easier in +future to support languages other than C and C++. Second, configurable +code can make use of advanced preprocessing facilities such as loops +and recursion. The disadvantage is that component writers would have +to learn about a new preprocessor and embed appropriate directives in +the code. This makes it much more difficult to turn existing code into +components, and it involves extra training costs for the component +writers. + + + + +Compiler optimizations can be used to elide code that should not be +present, for example: + + + … + if (CYGHWR_NUMBER_UARTS > 0) { + … + } + … + + +If the compiler knows that CYGHWR_NUMBER_UARTS is +the constant number 0 then it is a trivial operation to get rid of the +unnecessary code. The component framework still has to define this +symbol in a way that is acceptable to the compiler, typically by using +a const variable or a preprocessor symbol. In some +respects this is a clean approach to configurability, but it has +limitations. It cannot be used in the declarations of data structures +or classes, nor does it provide control over entire functions. In +addition it may not be immediately obvious that this code is affected +by configuration options, which may make it more difficult to +understand. + + + + +Existing language preprocessors can be used. In the case of C or C++ +this would be the standard C preprocessor, and configurable code would +contain a number of #ifdef and +#if statements. + + +#if (CYGHWR_NUMBER_UARTS > 0) + … +#endif + + +This approach has the big advantage that the C preprocessor is a +technology that is both well-understood and widely used. There are +also disadvantages: it is not directly applicable to components +written in other languages such as Java (although it is possible to +use the C preprocessor as a stand-alone program); the preprocessing +facilities are rather limited, for example there is no looping +facility; and some people consider the technology to be ugly. Of +course it may be possible to get around the second objection by +extending the preprocessor that is used by gcc and g++. + + + + + +The current component framework generates configuration header files +with C preprocessor #define's for each option +(typically, there various properties which can be used to control +this). It is up to component writers to decide whether to use +preprocessor #ifdef statements or language +constructs such as if. At present there is no +support for languages which do not involve the C preprocessor, +although such support can be added in future when the need arises. + + + + + + + + + + + +Exported Header Files + + +A package's exported header files should specify the interface +provided by that package, and avoid any implementation details. +However there may be performance or other reasons why implementation +details occasionally need to be present in the exported headers. + + + + +Not all programming languages have the concept of a header file. In +some cases the component framework would need extensions to support +packages written in such languages. + + + + +Configurability has a number of effects on the way exported header +files should be written. There may be configuration options which +affect the interface of a package, not just the implementation. It is +necessary to worry about nested #include's and how +this affects package and application builds. A special case of this +relates to whether or not exported header files should +#include configuration headers. These configuration +headers are exported, but should only be #include'd +when necessary. + + + +Configurable Functionality + + +Many configuration options affect only the implementation of a +package, not the interface. However some options will affect the +interface as well, which means that the options have to be tested in +the exported header files. Some implementation choices, for example +whether or not a particular function should be inlined, also need to +be tested in the header file because of language limitations. + + +Consider a configuration option +CYGFUN_KERNEL_MUTEX_TIMEDLOCK which controls +whether or not a function cyg_mutex_timedlock is +provided. The exported kernel header file cyg/kernel/kapi.h could contain the +following: + + + +#include <pkgconf/kernel.h> +… +#ifdef CYGFUN_KERNEL_MUTEX_TIMEDLOCK +extern bool cyg_mutex_timedlock(cyg_mutex_t*); +#endif + + + +This is a correct header file, in that it defines the exact interface +provided by the package at all times. However is has a number of +implications. First, the header file is now dependent on pkgconf/kernel.h, so any changes to +kernel configuration options will cause cyg/kernel/kapi.h to be out of date, and +any source files that use the kernel interface will need rebuilding. +This may affect sources in the kernel package, in other packages, and +in application source code. Second, if the application makes use of +this function somewhere but the application developer has +misconfigured the system and disabled this functionality anyway then +there will now be a compile-time error when building the application. +Note that other packages should not be affected, since they should +impose appropriate constraints on +CYGFUN_KERNEL_MUTEX_TIMEDLOCK if they use that +functionality (although of course some dependencies like this may get +missed by component developers). + + +An alternative approach would be: + + + +extern bool cyg_mutex_timedlock(cyg_mutex_t*); + + + +Effectively the header file is now lying about the functionality +provided by the package. The first result is that there is no longer a +dependency on the kernel configuration header. The second result is +that an application file using the timed-lock function will now +compile, but the application will fail to link. At this stage the +application developer still has to intervene, change the +configuration, and rebuild the system. However no application +recompilations are necessary, just a relink. + + + +Theoretically it would be possible for a tool to analyze linker errors +and suggest possible configuration changes that would resolve the +problem, reducing the burden on the application developer. No such +tool is planned in the short term. + + + +It is up to component writers to decide which of these two approaches +should be preferred. Note that it is not always possible to avoid +#include'ing a configuration header file in an +exported one, for example an option may affect a data structure rather +than just the presence or absence of a function. Issues like this will +vary from package to package. + + + + + +Nested <literal>#include's</literal> + +As a general rule, unnecessary #include's should be +avoided. A header file should #include only those +header files which are absolutely needed for it to define its +interface. Any additional #include's make it more +likely that package or application source files become dependent on +configuration header files and will get rebuilt unnecessarily when +there are minor configuration changes. + + + + +Including Configuration Headers + +Exported header files should avoid #include'ing +configuration header files unless absolutely necessary, to avoid +unnecessary rebuilding of both application code and other packages +when there are minor configuration changes. A +#include is needed only when a configuration option +affects the exported interface, or when it affects some implementation +details which is controlled by the header file such as whether or not +a particular function gets inlined. + + +There are a couple of ways in which the problem of unnecessary +rebuilding could be addressed. The first would require more +intelligent handling of header file dependency handling by the tools +(especially the compiler) and the build system. This would require +changes to various non-eCos tools. An alternative approach would be to +support finer-grained configuration header files, for example there +could be a file pkgconf/libc/inline.h controlling which +functions should be inlined. This could be achieved by some fairly +simple extensions to the component framework, but it makes it more +difficult to get the package header files and source code correct: +a C preprocessor #ifdef directive does not +distinguish between a symbol not being defined because the option is +disabled, or the symbol not being defined because the appropriate +configuration header file has not been #include'd. +It is likely that a cross-referencing tool would have to be developed +first to catch problems like this, before the component framework +could support finer-grained configuration headers. + + + + + + + + + +Package Documentation + +On-line package documentation should be in HTML format. The component +framework imposes no special limitations: component writers can decide +which version of the HTML specification should be followed; they can +also decide on how best to cope with the limitations of different +browsers. In general it is a good idea to keep things simple. + + + + + + + +Test Cases + +Packages should normally come with one or more test cases. This allows +application developers to verify that a given package works correctly +on their particular hardware and in their particular configuration, +making it slightly more likely that they will attempt to find bugs in +their own code rather than automatically blaming the component +writers. + + +At the time of writing the application developer support for building +and running test cases via the component framework is under review and +likely to change. Currently each test case should consist of a single +C or C++ source file that can be compiled with the package's set of +compiler flags and linked like any application program. Each test case +should use the testing API defined by the infrastructure. A +magically-named calculated configuration option of the form +CYGPKG_<PACKAGE-NAME>_TESTS lists the test +cases. + + + + + + + +Host-side Support + +On occasion it would be useful for an &eCos; package to be shipped +with host-side support. This could take the form of an additional tool +needed to build that package. It could be an application intended to +communicate with the target-side package code and display monitoring +information. It could be a utility needed for running the package test +cases, especially in the case of device drivers. The component +framework does not yet provide any such support for host-side +software, and there are obvious issues related to portability to the +different machines that can be used for hosts. This issue may get +addressed in some future release. In some cases custom build steps can +be subverted to do things on the host side rather than the target +side, but this is not recommended. + + + + + + + + + + + +Making a Package Distribution + + +Developers of new &eCos; packages are advised to distribute their +packages in the form of &eCos; package distribution files. Packages +distributed in this format may be added to existing &eCos; component +repositories in a robust manner using the Package Administration Tool. +This chapter describes the format of package distribution files and +details how to prepare an eCos package for distribution in this format. + + + +The &eCos; package distribution file format + + +eCos package distribution files are gzipped GNU tar archives which +contain both the source code for one or more &eCos; packages and a +data file containing package information to be added to the component +repository database. The distribution files are subject to the +following rules: + + + + +The data file must be named pkgadd.db and must be +located in the root of the tar archive. It must contain data in a +format suitable for appending to the eCos repository database +(ecos.db). +describes this data format. Note that a database consistency check is +performed by the &eCos; Administration Tool when +pkgadd.db has been appended to the database. Any +new target entries which refer to unknown packages will be removed at +this stage. + + + + +The package source code must be placed in one or more <package-path>/<version> +directories in the tar archive, where each <package-path> +directory path is specified as the directory attribute of one of the +packages entries in pkgadd.db. + + + + +An optional license agreement file named +pkgadd.txt may be placed in the root of the tar +archive. It should contain text with a maximum line length of 79 +characters. If this file exists, the contents will be presented to the +user during installation of the package. The &eCos; Package +Administration Tool will then prompt the user with the question +"Do you accept all the terms of the preceding license +agreement?". The user must respond +"yes" to this prompt in order to proceed with +the installation. + + + + +Optional template files may be placed in one or more templates/<template_name> +directories in the tar archive. Note that such template files would be +appropriate only where the packages to be distributed have a complex +dependency relationship with other packages. Typically, a third party +package can be simply added to an eCos configuration based on an +existing core template and the provision of new templates would not be +appropriate. contains more +information on templates. + + + + +The distribution file must be given a .epk (not +.tar.gz) file extension. The +.epk file extension serves to distinguish &eCos; +package distributions files from generic gzipped GNU tar archives. It +also discourages users from attempting to extract the package from the +archive manually. The file browsing dialog of the &eCos; Package +Administration Tool lists only those files which have a +.epk extension. + + + + +No other files should be present in the archive. + + + + +Files in the tar archive may use LF or +CRLF line endings interchangably. The &eCos; +Administration Tool ensures that the installed files are given the +appropriate host-specific line endings. + + + + +Binary files may be placed in the archive, but the distribution of +object code is not recommended. All binary files must be given a +.bin suffix in addition to any file extension they +may already have. For example, the GIF image file +myfile.gif must be named +myfile.gif.bin in the archive. The +.bin suffix is removed during file extraction and +is used to inhibit the manipulation of line endings by the &eCos; +Administration Tool. + + + + + + +Preparing eCos packages for distribution + + +Development of new &eCos; packages or new versions of existing &eCos; +packages will take place in the context of an existing &eCos; +component repository. This section details the steps involved in +extracting new packages from a repository and generating a +corresponding &eCos; package distribution file for distribution of the +packages to other &eCos; users. The steps required are as follows: + + + + + +Create a temporary directory $PKGTMP for manipulation of the package +distribution file contents and copy the source files of the new +packages into this directory, preserving the relative path to the +package. In the case of a new package at mypkg/current in the repository: + + + $ mkdir -p $PKGTMP/mypkg + $ cp -p -R $ECOS_REPOSITORY/mypkg/current $PKGTMP/mypkg + + +Where more than one package is to be distributed in a single package +distribution file, copy each package in the above manner. Note that +multiple packages distributed in a single package distribution file +cannot be installed separately. Where such flexibility is required, +distribution of each new package in separate package distribution files +is recommended. + + + + +Copy any template files associated with the distributed packages into +the temporary directory, preserving the relative path to the template. +For example: + + + $ mkdir -p $PKGTMP/templates + $ cp -p -R $ECOS_REPOSITORY/templates/mytemplate $PKGTMP/templates + + + + +Remove any files from the temporary directory hierarchy which you do +not want to distribute with the packages (eg object files, CVS directories). + + + + +Add a .bin suffix to the name of any binary +files. For example, if the packages contains GIF image files (*.gif) +for documentation purposes, such files must be renamed to *.gif.bin as +follows: + + + $ find $PKGTMP -type f -name '*.gif' -exec mv {} {}.bin ';' + + +The .bin suffix is removed during file extraction +and is used to inhibit the manipulation of line endings by the eCos +Package Administration Tool. + + + + +Extract the package records for the new packages from the package +database file at $ECOS_REPOSITORY/ecos.db and +create a new file containing these records at +$PKGTMP/pkgadd.db (in the root of the temporary +directory hierarchy). Any target records which reference the +distributed packages must also be provided in pkgadd.db. + + + + +Rename the version directories under $PKGTMP (typically current during development) to reflect +the versions of the packages you are distributing. For example, +version 1.0 of a package may use the version directory name v1_0: + + + $ cd $PKGTMP/mypkg + $ mv current v1_0 + + + describes the version naming +conventions. + + + + +Rename any template files under $PKGTMP (typically +current.ect during development) to reflect the +version of the template you are distributing. For example, version 1.0 +of a template may use the filename v1_0.ect: + + + $ cd $PKGTMP/templates/mytemplate + $ mv current.ect v1_0.ect + + +It is also important to edit the contents of the template file, changing +the version of each referenced package to match that of the packages you +are distributing. This step will eliminate version warnings during the +subsequent loading of the template. + + + + +Optionally create a licence agreement file at +$PKGTMP/pkgadd.txt containing the licensing terms +under which you are distributing the new packages. Limit each line in +this file to a maximum of 79 characters. + + + + +Create a GNU tar archive of the temporary directory hierarchy. By +convention, this archive would have a name of the form +<package_name>-<version>: + + + $ cd $PKGTMP + $ tar cf mypkg-1.0.tar * + + +Note that non-GNU version of tar may create archive files which exhibit +subtle incompatibilities with GNU tar. For this reason, always use GNU +tar to create the archive file. + + + + +Compress the archive using gzip and give the resulting file a +.epk file extension: + + + $ gzip mypkg-1.0.tar + $ mv mypkg-1.0.tar.gz mypkg-1.0.epk + + +The resulting eCos package distribution file (*.epk) is in a compressed +format and may be distributed without further compression. + + + + + + + + + + + \ No newline at end of file diff --git a/host/libcdl/doc/reference.sgml b/host/libcdl/doc/reference.sgml new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/reference.sgml @@ -0,0 +1,3880 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +CDL Language Specification + + +This chapter contains reference information for the main &CDL; +commands &cdl-option;, &cdl-component;, &cdl-package; and +&cdl-interface;, followed by the various properties such as +&active-if; and &compile; in alphabetical order. + + + + + + +&cdl-option; + + + +Command &cdl-option; +Define a single configuration option + + + + +cdl_option <name> { + … +} + + + +Description + +The option is the basic unit of configurability. Generally each option +corresponds to a single user choice. Typically there is a certain +amount of information associated with an option to assist the user in +manipulating that option, for example a textual description. There +will also be some limits on the possible values that the user can +choose, so an option may be a simple yes-or-no choice or it may be +something more complicated such as an array size or a device name. +Options may have associated constraints, so if that option is enabled +then certain conditions have to satisfied elsewhere in the +configuration. Options usually have direct consequences such as +preprocessor #define symbols in a configuration +header file. + + +&cdl-option; is implemented as a Tcl command that takes two arguments, +a name and a body. The name must be a valid C preprocessor identifier: +a sequence of upper or lower case letters, digits or underscores, +starting with a non-digit character; identifiers beginning with an +underscore should normally be avoided because they may clash with +system packages or with identifiers reserved for use by the compiler. +Within a single configuration, names must be unique. If a +configuration contained two packages which defined the same entity +CYGIMP_SOME_OPTION, any references to that entity +in a &requires; property or any other expression +would be ambiguous. It is possible for a given name to be used by two +different packages if those packages should never be loaded into a +single configuration. For example, architectural HAL packages are +allowed to re-use names because a single configuration cannot target +two different architectures. For a recommended naming convention see +. + + +The second argument to cdl_option is a body of +properties, typically surrounded by braces so that the Tcl interpreter +treats it as a single argument. This body will be processed by a +recursive invocation of the Tcl interpreter, extended with additional +commands for the various properties that are allowed inside a +&cdl-option;. The valid properties are: + + + + +&active-if; + +Allow additional control over the active state of this option. + + +&calculated; + +The option's value is not directly user-modifiable, it is calculated +using a suitable CDL expression. + + +&compile; + +List the source files that should be built if this option is active +and enabled. + + +&default-value; + +Provide a default value for this option using a CDL expression. + + +&define; + +Specify additional #define symbols that should go +into the owning package's configuration header file. + + +&define-format; + +Control how the option's value will appear in the configuration header +file. + + +&define-proc; + +Use a fragment of Tcl code to output additional data to +configuration header files. + + +&description; + +Provide a textual description for this option. + + +&display; + +Provide a short string describing this option. + + +&doc; + +The location of on-line documentation for this option. + + +&flavor; + +Specify the nature of this option. + + +&if-define; + +Output a common preprocessor construct to a configuration header file. + + +&implements; + +Enabling this option provides one instance of a more general +interface. + + +&legal-values; + +Impose constraints on the possible values for this option. + + +&make; + +An additional custom build step associated with this option, resulting +in a target that should not go directly into a library. + + +&make-object; + +An additional custom build step associated with this option, resulting +in an object file that should go into a library. + + +&no-define; + +Suppress the normal generation of a preprocessor +#define symbol in a configuration header file. + + +&parent; + +Control the location of this option in the configuration hierarchy. + + +&requires; + +List constraints that the configuration should satisfy if this option is +active and enabled. + + + + + + +Example + +cdl_option CYGDBG_INFRA_DEBUG_PRECONDITIONS { + display "Preconditions" + default_value 1 + description " + This option allows individual control of preconditions. + A precondition is one type of assert, which it is + useful to control separately from more general asserts. + The function is CYG_PRECONDITION(condition,msg)." +} + + + +See Also + +Command &cdl-component;, +command &cdl-package;, +command &cdl-interface;. + + + + + + + + + + +&cdl-component; + + + +Command &cdl-component; +Define a component, a collection of configuration options + + + + +cdl_component <name> { + … +} + + + +Description + +A component is a configuration option that can contain additional +options and sub-components. The body of a &cdl-component; can contain +the same properties as that of a &cdl-option;. There is an additional +property, &script; which allows configuration data to be split into +multiple files. It is also possible for a component body to include +&cdl-component;, &cdl-option; and &cdl-interface; entities that should +go below this component in the configuration hierarchy. + + +&cdl-component; is implemented as a Tcl command that takes two +arguments, a name and a body. The name must be a valid C preprocessor +identifier: a sequence of upper or lower case letters, digits or +underscores, starting with a non-digit character; identifiers +beginning with an underscore should normally be avoided because they +may clash with system packages or with identifiers reserved for use by +the compiler. Within a single configuration, names must be unique. If +a configuration contained two packages which defined the same entity +CYGIMP_SOME_OPTION, any references to that entity +in a &requires; property or any other expression would be ambiguous. +It is possible for a given name to be used by two different packages +if those packages should never be loaded into a single configuration. +For example, architectural HAL packages are allowed to re-use certain +names because a single configuration cannot target two different +architectures. For a recommended naming convention see . + + +The second argument to &cdl-component; is a body of properties and +other commands, typically surrounded by braces so that the Tcl +interpreter treats it as a single argument. This body will be +processed by a recursive invocation of the Tcl interpreter, extended +with additional commands for the various properties that are allowed +inside a &cdl-component;. The valid commands are: + + + + +&active-if; + +Allow additional control over the active state of this component. + + +&calculated; + +The component's value is not directly user-modifiable, it is calculated +using a suitable CDL expression. + + +&cdl-component + +Define a sub-component. + + +&cdl-interface; + +Define an interface which should appear immediately below this +component in the configuration hierarchy. + + +&cdl-option; + +Define a configuration option which should appear immediately below +this component in the configuration hierarchy. + + +&compile; + +List the source files that should be built if this component is active +and enabled. + + +&default-value; + +Provide a default value for this component using a CDL expression. + + +&define; + +Specify additional #define symbols that should go +into the owning package's configuration header file. + + +&define-format; + +Control how the component's value will appear in the configuration header +file. + + +&define-proc; + +Use a fragment of Tcl code to output additional data to +configuration header files. + + +&description; + +Provide a textual description for this component. + + +&display; + +Provide a short string describing this component. + + +&doc; + +The location of on-line documentation for this component. + + +&flavor; + +Specify the nature of this component. + + +&if-define; + +Output a common preprocessor construct to a configuration header file. + + +&implements; + +Enabling this component provides one instance of a more general +interface. + + +&legal-values; + +Impose constraints on the possible values for this component. + + +&make; + +An additional custom build step associated with this component, resulting +in a target that should not go directly into a library. + + +&make-object; + +An additional custom build step associated with this component, resulting +in an object file that should go into a library. + + +&no-define; + +Suppress the normal generation of a preprocessor +#define symbol in a configuration header file. + + +&parent; + +Control the location of this component in the configuration hierarchy. + + +&requires; + +List constraints that the configuration should satisfy if this component is +active and enabled. + + +&script; + +Include additional configuration information from another +CDL script + + + + + + +Example + + +cdl_component CYGDBG_USE_ASSERTS { + display "Use asserts" + default_value 1 + description " + If this component is enabled, assertions in the code are + tested at run-time. Assert functions (CYG_ASSERT()) are + defined in 'include/cyg/infra/cyg_ass.h' within the 'install' + tree. If the component is disabled, these result in no + additional object code and no checking of the asserted + conditions." + script assert.cdl +} + + + + +See Also + +Command &cdl-option;, +command &cdl-package;, +command &cdl-interface;. + + + + + + + + + + +&cdl-package; + + + +Command &cdl-package; +Define a package, a component that can be distributed + + + + +cdl_package <name> { + … +} + + + +Description + +A package is a unit of distribution. It is also a configuration option +in that users can choose whether or not a particular package is loaded +into the configuration, and which version of that package should be +loaded. It is also a component in that it can contain additional +components and options in a hierarchy. + + +The top-level &CDL; script for a package should begin with a &cdl-package; +command. This can contain most of the properties that can be used in a +&cdl-option; command, and a number of additional ones which apply to a +package as a whole. It is also possible to include &cdl-component;, +&cdl-interface; and &cdl-option; commands in the body of a package. +However all configuration entities that occur at the top level of the +script containing the &cdl-package; command are automatically placed +below that package in the configuration hierarchy, so putting them +inside the body has no effect. + + +The following properties cannot be used in the body of a &cdl-package; +command: + + + +&flavor; + +Packages always have the flavor booldata. + + +&default-value; + +The value of a package is its version number. This is specified at the +time the package is loaded into the configuration, and cannot be +calculated afterwards. Typically the most recent version of the +package will be loaded. + + +&legal-values; + +The legal values list for a given package is determined by which +versions of that package are installed in the component repository, +and cannot be further constrained in the CDL scripts. + + +&calculated; + +The value of a package is always selected at the time that it is +loaded into the configuration, and cannot be re-calculated afterwards. + + +&script; + +This would be redundant since the CDL script containing the +&cdl-package; command acts as that package's script. + + + + + +&cdl-package; is implemented as a Tcl command that takes two +arguments, a name and a body. The name must be a valid C preprocessor +identifier: a sequence of upper or lower case letters, digits or +underscores, starting with a non-digit character; identifiers +beginning with an underscore should normally be avoided because they +may clash with system packages or with identifiers reserved for use by +the compiler. Packages should always have unique names within a given +component repository. For a recommended naming convention see . + + +The second argument to &cdl-package; is a body of properties and other +commands, typically surrounded by braces so that the Tcl interpreter +treats it as a single argument. This body will be processed by a +recursive invocation of the Tcl interpreter, extended with additional +commands for the various properties that are allowed inside a +&cdl-package;. The valid commands are: + + + + +&active-if; + +Allow additional control over the active state of this package. + + +&cdl-component; + +Define a component which should appear immediately below this package +in the configuration hierarchy. + + +&cdl-interface; + +Define an interface which should appear immediately below this +package in the configuration hierarchy. + + +&cdl-option; + +Define an option which should appear immediately below +this package in the configuration hierarchy. + + +&compile; + +List the source files that should be built for this package. + + +&define; + +Specify additional #define symbols that should go +into the package's configuration header file. + + +&define-format; + +Control how the package's value will appear in the global +configuration header file pkgconf/system.h + + +&define-header; + +Specify the configuration header file that will be generated for this package. + + +&define-proc; + +Use a fragment of Tcl code to output additional data to +configuration header files. + + +&description; + +Provide a textual description for this component. + + +&display; + +Provide a short string describing this component. + + +&doc; + +The location of on-line documentation for this component. + + +&hardware; + +This package is tied to specific hardware. + + +&if-define; + +Output a common preprocessor construct to a configuration header file. + + +&implements; + +Enabling this component provides one instance of a more general +interface. + + +&include-dir; + +Specify the desired location of this package's exported header files in +the install tree. + + +&include-files; + +List the header files that are exported by this package. + + +&library; + +Specify which library should contain the object files +generated by building this package. + + +&make; + +An additional custom build step associated with this component, resulting +in a target that should not go directly into a library. + + +&make-object; + +An additional custom build step associated with this component, resulting +in an object file that should go into a library. + + +&no-define; + +Suppress the normal generation of the package's +#define in the global configuration header file +pkgconf/system.h. + + +&parent; + +Control the location of this package in the configuration hierarchy. + + +&requires; + +List constraints that the configuration should satisfy if this package is +active. + + + + + + + +Example + +cdl_package CYGPKG_INFRA { + display "Infrastructure" + include_dir cyg/infra + description " + Common types and useful macros. + Tracing and assertion facilities. + Package startup options." + + compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx \ + dummyxxmain.cxx null.cxx simple.cxx fancy.cxx buffer.cxx \ + diag.cxx tcdiag.cxx memcpy.c memset.c delete.cxx +} + + + + +See Also + +Command &cdl-option;, +command &cdl-component;, +command &cdl-interface;. + + + + + + + + + + +&cdl-interface; + + + +Command &cdl-interface; +Define an interface, functionality that can be provided by +a number of different implementations. + + + + +cdl_interface <name> { + … +} + + + +Description + +An interface is a special type of calculated configuration option. +It provides an abstraction mechanism that is often useful in &CDL; +expressions. As an example, suppose that some package relies on the +presence of code that implements the standard kernel scheduling +interface. However the requirement is no more stringent than this, so +the constraint can be satisfied by the mlqueue scheduler, the bitmap +scheduler, or any additional schedulers that may get implemented in +future. A first attempt at expressing the dependency might be: + + + requires CYGSEM_KERNEL_SCHED_MLQUEUE || CYGSEM_KERNEL_SCHED_BITMAP + + +This constraint is limited, it may need to be changed if a new +scheduler were to be added to the system. Interfaces provide a way of +expressing more general relationships: + + + requires CYGINT_KERNEL_SCHEDULER + + +The interface CYGINT_KERNEL_SCHEDULER is +implemented by both the mlqueue and bitmap +schedulers, and may be implemented by future schedulers as well. The +value of an interface is the number of implementors that are active +and enabled, so in a typical configuration only one scheduler will be +in use and the value of the interface will be 1. If +all schedulers are disabled then the interface will have a value +0 and the &requires; constraint will not be +satisfied. + + +Some component writers may prefer to use the first &requires; +constraint on the grounds that the code will only have been tested +with the mlqueue and bitmap schedulers and cannot be guaranteed to +work with any new schedulers. Other component writers may take a more +optimistic view and assume that their code will work with any +scheduler until proven otherwise. + + +Interfaces must be defined in CDL scripts, just like options, +components and packages. This involves the command &cdl-interface; +which takes two arguments, a name and a body. The name must be a valid +C preprocessor identifier: a sequence of upper or lower case letters, +digits or underscores, starting with a non-digit character; +identifiers beginning with an underscore should normally be avoided +because they may clash with system packages or with identifiers +reserved for use by the compiler. Within a single configuration, names +must be unique. If a configuration contained two packages which +defined the same entity CYGIMP_SOME_OPTION, any +references to that entity in a &requires; property or any other +expression would be ambiguous. It is possible for a given name to be +used by two different packages if those packages should never be +loaded into a single configuration. For example, architectural HAL +packages are allowed to re-use names because a single configuration +cannot target two different architectures. For a recommended naming +convention see . + + +The second argument to &cdl-interface; is a body of properties, +typically surrounded by braces so that the Tcl interpreter treats it +as a single argument. This body will be processed by a recursive +invocation of the Tcl interpreter, extended with additional commands +for the various properties that are allowed inside a &cdl-interface;. +The valid properties are a subset of those for a &cdl-option;. + + + + +&active-if; + +Allow additional control over the active state of this interface. + + +&compile; + +List the source files that should be built if this interface is active. + + +&define; + +Specify additional #define symbols that should go +into the owning package's configuration header file. + + +&define-format; + +Control how the interface's value will appear in the configuration header +file. + + +&define-proc; + +Use a fragment of Tcl code to output additional data to +configuration header files. + + +&description; + +Provide a textual description for this interface. + + +&display; + +Provide a short string describing this interface. + + +&doc; + +The location of on-line documentation for this interface. + + +&flavor; + +Interfaces have the data flavor by default, but +they can also be given the bool or +booldata flavor when necessary. A +bool interface is disabled if there are no active +and enabled implementors, otherwise it is enabled. A +booldata interface is also disabled if there are no +active and enabled implementors, otherwise it is enabled and the data +is a number corresponding to the number of these implementors. + + +&if-define; + +Output a common preprocessor construct to a configuration header file. + + +&implements; + +If this interface is active it provides one instance of a more general +interface. + + +&legal-values; + +Interfaces always have a small numerical value. The &legal-values; can +be used to apply additional constraints such as an upper limit. + + +&make; + +An additional custom build step associated with this option, resulting +in a target that should not go directly into a library. + + +&make-object; + +An additional custom build step associated with this option, resulting +in an object file that should go into a library. + + +&no-define; + +Suppress the normal generation of a preprocessor +#define symbol in a configuration header file. + + +&parent; + +Control the location of this option in the configuration hierarchy. + + +&requires; + +List constraints that the configuration should satisfy if this option is +active and enabled. + + + + + +A number of properties are not applicable to interfaces: + + + +&calculated; + +Interfaces are always calculated, based on the number of active and +enabled entities that implement the interface. + + +&default-value; + +Interface values are calculated so a &default-value; property would be +meaningless. + + + + + +Interfaces are not containers, so they cannot hold other entities such +as options or components. + + +A commonly used constraint on interface values takes the form: + + + requires CYGINT_KERNEL_SCHEDULER == 1 + + +This constraint specifies that there can be only one scheduler in the +system. In some circumstances it is possible for the configuration +tools to detect this pattern and act accordingly, so for example +enabling the bitmap scheduler would automatically disable the mlqueue +scheduler. + + + + +Example + +cdl_interface CYGINT_KERNEL_SCHEDULER { + display "Number of schedulers in this configuration" + requires 1 == CYGINT_KERNEL_SCHEDULER +} + + + +See Also + +Property &implements;, +command &cdl-option;. +command &cdl-component;, +command &cdl-package;. + + + + + + + + + + + +&active-if; + + + +Property &active-if; +Allow additional control over the active state of an +option or other CDL entity. + + + + +cdl_option <name> { + active_if <condition> + … +} + + + +Description + +Configuration options or other entities may be either active or +inactive. Typically this is controlled by the option's location in the +overall hierarchy. Consider the option +CYGDBG_INFRA_DEBUG_PRECONDITIONS, which exists +below the component CYGDBG_USE_ASSERT. If the whole +component is disabled then the options it contains are inactive: there +is no point in enabling preconditions unless there is generic +assertion support; any &requires; constraints associated with +preconditions are irrelevant; any &compile; property or other +build-related property is ignored. + + +In some cases the hierarchy does not provide sufficient control over +whether or not a particular option should be active. For example, the +math library could have support for floating point exceptions which +is only worthwhile if the hardware implements appropriate +functionality, as specified by the architectural HAL. The relevant +math library configuration options should remain below the +CYGPKG_LIBM package in the overall hierarchy, but +should be inactive unless there is appropriate hardware support. In +cases like this an &active-if; property is appropriate. + + +Another common use of &active-if; properties is to avoid excessive +nesting in the configuration hierarchy. If some option B is only +relevant if option A is enabled, it is possible to turn A into a +component that contains B. However adding another level to the +hierarchy for a component which will contain just one entry may be +considered excessive. In such cases it is possible for B to have an +&active-if; dependency on A. + + +&active-if; takes a goal expression as argument. For details of goal +expression syntax see . In +most cases the goal expression will be very simple, often involving +just one other option, but more complicated expressions can be used +when appropriate. It is also possible to have multiple &active-if; +conditions in a single option, in which case all of the conditions +have to be satisfied if the option is to be active. + + +The &active-if; and &requires; properties have certain similarities, +but they serve a different purpose. Suppose there are two options A +and B, and option B relies on functionality provided by A. This could +be expressed as either active_if A or as +requires A. The points to note are: + + + + +If active_if A is used and A is disabled or +inactive, then graphical tools will generally prevent any attempt at +modifying B. For example the text for B could be grayed out, and the +associated checkbutton (if B is a boolean option) would be disabled. +If the user needs the functionality provided by option B then it is +necessary to go to option A first and manipulate it appropriately. + + + +If requires A is used and A is disabled or +inactive, graphical tools will still allow B to be manipulated and +enabled. This would result in a new conflict which may get resolved +automatically or which may need user intervention. + + + +If there are hardware dependencies then an &active-if; condition is +usually the preferred approach. There is no point in allowing the user +to manipulate a configuration option if the corresponding +functionality cannot possibly work on the currently-selected hardware. +Much the same argument applies to coarse-grained dependencies, for +example if an option depends on the presence of a TCP/IP stack then an +active_if CYGPKG_NET condition is appropriate: +it may be possible to satisfy the condition, but it requires the +fairly drastic step of loading another package; further more, if the +user wanted a TCP/IP stack in the configuration then it would probably +have been loaded already. + + +If option B exists to provide additional debugging information about +the functionality provided by A then again an &active-if; constraint +is appropriate. There is no point in letting users enable extra +debugging facilities for a feature that is not actually present. + + + +The configuration system's inference engine will cope equally well +with &active-if; and &requires; properties. Suppose there is a +conflict because some third option depends on B. If B is +active_if A then the inference engine will +attempt to make A active and enabled, and then to enable B if +necessary. If B requires A then the inference +engine will attempt to enable B and resolve the resulting conflict by +causing A to be both active and enabled. Although the inference occurs +in a different order, in most cases the effect will be the same. + + + + + + +Example + +# Do not provide extra semaphore debugging if there are no semaphores +cdl_option CYGDBG_KERNEL_INSTRUMENT_BINSEM { + active_if CYGPKG_KERNEL_SYNCH + … +} + +# Avoid another level in the configuration hierarchy +cdl_option CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE_RELAY { + active_if CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INHERITANCE_SIMPLE + … +} + +# Functionality that is only relevant if another package is loaded +cdl_option CYGSEM_START_UITRON_COMPATIBILITY { + active_if CYGPKG_UITRON + … +} + +# Check that the hardware or HAL provide the appropriate functionality +cdl_option CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT { + active_if CYGINT_HAL_DEBUG_GDB_STUBS_BREAK + … +} + + + +See Also + +Property &requires;. + + + + + + + + + + +&calculated; + + + +Property &calculated; +Used if the current option's value is not user-modifiable, +but is calculated using a suitable CDL expression. + + + + +cdl_option <name> { + calculated <expression> + … +} + + + +Description + +In some cases it is useful to have a configuration option whose value +cannot be modified directly by the user. This can be achieved using a +&calculated;, which takes a CDL expression as argument (see for a description of expression +syntax). The configuration system evaluates the expression when the +current package is loaded and whenever there is a change to any other +option referenced in the expression. The result depends on the +option's flavor: + + + + +flavor none + +Options with this flavor have no value, so the &calculated; +property is not applicable. + + +flavor bool + +If the expression evaluates to a non-zero result the option is +enabled, otherwise it is disabled. + + +flavor booldata + +If the result of evaluating the expression is zero then the option is +disabled, otherwise the option is enabled and its value is the result. + + +flavor data + +The value of the option is the result of evaluating the expression. + + + + + +There are a number of valid uses for calculated options, and there are +also many cases where some other CDL facility would be more +appropriate. Valid uses of calculated options include the following: + + + + +On some target hardware a particular feature may be user-configurable, +while on other targets it is fixed. For example some processors can +operate in either big-endian or little-endian mode, while other +processors do not provide any choice. It is possible to have an +option CYGARC_BIGENDIAN which is calculated in +some architectural HAL packages but user-modifiable in others. + + + +Calculated options can provide an alternative way for one package to +affect the behavior of another one. Suppose a package may provide two +possible implementations, a preferred one involving self-modifying +code and a slower alternative. If the system involves a ROM bootstrap +then the slower alternative must be used, but it would be +inappropriate to modify the startup option in every HAL to impose +constraints on this package. Instead it is possible to have a +calculated option whose value is +{ CYG_HAL_STARTUP == "ROM" }, +and which has appropriate consequences. Arguably this is a spurious +example, and it should be a user choice whether or not to use +self-modifying code with a &default-value; based on +CYG_HAL_STARTUP, but that is for the component +writer to decide. + + + +Sometimes it should be possible to perform a particular test at +compile-time, for example by using a C preprocessor +#if construct. However the preprocessor has only +limited functionality, for example it cannot perform string +comparisons. CDL expressions are more powerful. + + + +Occasionally a particular sub-expression may occur multiple times in +a CDL script. If the sub-expression is sufficiently complex then it +may be worthwhile to have a calculated option whose value is the +sub-expression, and then reference that calculated option in the +appropriate places. + + + + + +Alternatives to using calculated options include the following: + + + + +CDL interfaces are a form of +calculated option intended as an abstraction mechanism. An interface +can be used to express the concept of any +scheduler, as opposed to a specific one such as the bitmap scheduler. + + + +If a calculated option would serve only to add additional information +to a configuration header file, it may be possible to achieve the same +effect using a &define-proc +property or one of the other properties related to header file +generation. + + + + + + +If the first entry in a &calculated; expression is a negative +number, for example calculated -1 then this +can be misinterpreted as an option instead of as part of the +expression. Currently the &calculated; property does not take any +options, but this may change in future. Option processing halts at the +sequence --, so the desired value can be expressed +safely using +calculated -- -1 + + + + + +Some of the CDL scripts in current &eCos; releases make excessive use +of calculated options. This is partly because the recommended +alternatives were not always available at the time the scripts were +written. It is also partly because there is still some missing +functionality, for example &define-proc; properties cannot yet access +the configuration data so it may be necessary to use &calculated; +properties to access the data and perform the desired manipulation via +a &CDL; expression. New scripts should use calculated options only in +accordance with the guidelines. + + + + + +For options with the booldata flavor the current CDL syntax does not +allow the enabled flag and the value to be calculated separately. +Functionality to permit this may be added in a future release. + + + + + +It has been suggested that having options which are not +user-modifiable is potentially confusing, and that a top-level +cdl_constant command should be added to the +language instead of or in addition to the &calculated; property. Such +a change is under consideration. However because the value of a +calculated option can depend on other options, it is not necessarily +constant. + + + + + +Example + +# A constant on some target hardware, perhaps user-modifiable on other +# targets. +cdl_option CYGNUM_HAL_RTC_PERIOD { + display "Real-time clock period" + flavor data + calculated 12500 +} + + + +See Also + +Properties &default-value;, +&flavor; and +&legal-values;, + + + + + + + + + + +&compile; + + + +Property &compile; +List the source files that should be built if this option +is active and enabled. + + + + +cdl_option <name> { + compile [-library=libxxx.a] <list of files> + … +} + + + +Description + +The &compile; property allows component developers to specify source +files which should be compiled and added to one of the target +libraries. Usually each source file will end up the library +libtarget.a. It is possible for component writers +to specify an alternative library for an entire package using the +&library; property. Alternatively +the desired library can be specified on the &compile; line itself. For +example, to add a particular source file to the +libextras.a library the following could be used: + + +cdl_package CYGPKG_IO_SERIAL { + … + compile -library=libextras.a common/tty.c +} + + +Details of the build process including such issues as compiler flags +and the order in which things happen can be found in +. + + +&compile; properties can occur in any of &cdl-option;, +&cdl-component;, &cdl-package; or &cdl-interface;. A &compile; +property has effect if and only if the entity that contains it is +active and enabled. Typically the body of a &cdl-package; will define +any source files that need to be built irrespective of individual +options, and each &cdl-component;, &cdl-option;, and &cdl-interface; +will define source files that are more specific. A single &compile; +property can list any number of source files, all destined for the +same library. A &cdl-option; or other entity can contain multiple +&compile; properties, each of which can specify a different library. +It is possible for a given source file to be specified in &compile; +properties for several different options, in which case the source +file will get built if any of these options are active and enabled. + + +If the package follows the directory +layout conventions then the configuration tools will search for +the specified source files first in the +src subdirectory of the +package, then relative to the package directory itself. + + + + +A shortcoming of the current specification of &compile; properties is +that there is no easy way to specify source files that should be built +unless an option is enabled. It would sometimes be useful to be able +to say: “if option A is enabled then compile +file x.c, otherwise compile file +y.c. There are two simple ways of achieving this: + + + +Always compile y.c, typically by listing it in +the body of the &cdl-package;, but use +#ifndef A to produce an empty object file if +option A is not enabled. This has the big +disadvantage that the file always gets compiled and hence for some +configurations builds will take longer than necessary. + + +Use a &calculated; option whose value is !A, and +have a compile y.c property in its body. This +has the big disadvantage of adding another calculated option to the +configuration. + + + +It is likely that this will be resolved in the future, possibly by +using some sort of expression as the argument to a &compile; property. + + + + + +Currently it is not possible to control the priority of a &compile; +property, in other words the order in which a file gets compiled +relative to other build steps. This functionality might prove useful +for complicated packages and should be added. + + + + +Example + +cdl_package CYGPKG_INFRA { + display "Infrastructure" + include_dir cyg/infra + description " + Common types and useful macros. + Tracing and assertion facilities. + Package startup options." + + compile startup.cxx prestart.cxx pkgstart.cxx userstart.cxx \ + dummyxxmain.cxx memcpy.c memset.c delete.cxx \ + diag.cxx tcdiag.cxx +} + + + +See Also + +Properties make, +make_object and +library. + + + + + + + + + + +&default-value; + + + +Property &default-value; +Provide a default value for this option using a CDL expression. + + + + +cdl_option <name> { + default_value <expression> + … +} + + + +Description + +The &default-value; property allows the initial value of a +configuration option to depend on other configuration options. The +arguments to the property should be a &CDL; expression, see + for the syntactic details. +In many cases a simple constant value will suffice, for example: + + +cdl_component CYGPKG_KERNEL_EXCEPTIONS { + … + default_value 1 + + cdl_option CYGSEM_KERNEL_EXCEPTIONS_DECODE { + … + default_value 0 + } +} + + +However it is also possible for an option's default value to depend on +other options. For example the common HAL package provides some +support functions that are needed by the &eCos; kernel, but are +unlikely to be useful if the kernel is not being used. This +relationship can be expressed using: + + +cdl_option CYGFUN_HAL_COMMON_KERNEL_SUPPORT { + ... + default_value CYGPKG_KERNEL +} + + +If the kernel is loaded then this HAL option is automatically enabled, +although the user can still disable it explicitly should this prove +necessary. If the kernel is not loaded then the option is disabled, +although it can still be enabled by the user if desired. +&default-value; expressions can be more complicated than this if +appropriate, and provide a very powerful facility for component +writers who want their code to “just do the right thing” +in a wide variety of configurations. + + +The &CDL; configuration system evaluates the &default-value; +expression when the current package is loaded and whenever there is a +change to any other option referenced in the expression. The result +depends on the option's flavor: + + + + +flavor none + +Options with this flavor have no value, so the &default-value; +property is not applicable. + + +flavor bool + +If the expression evaluates to a non-zero result the option is +enabled by default, otherwise it is disabled. + + +flavor booldata + +If the result of evaluating the expression is zero then the option is +disabled, otherwise the option is enabled and its value is the result. + + +flavor data + +The default value of the option is the result of evaluating the +expression. + + + + + +A &cdl-option; or other entity can have at most one &default-value; +property, and it is illegal to have both a &calculated; and a +&default-value; property in one body. If an option does not have +either a &default-value; or a &calculated; property and it does not +have the flavor none then the configuration tools +will assume a default value expression of 0. + + +On occasion it is useful to have a configuration option +A which has both a &requires; constraint on some +other option B and a &default-value; expression of +B. If option B is not enabled +then A will also be disabled by default and no +conflict arises. If B is enabled then +A also becomes enabled and again no conflict +arises. If a user attempts to enable B but not +A then there will be a conflict. Users should be +able to deduce that the two options are closely interlinked and should +not be manipulated independently except in very unusual circumstances. + + + + +If the first entry in a &default-value; expression is a negative +number, for example default_value -1 then this +can be misinterpreted as an option instead of as part of the +expression. Currently the &default-value; property does not take any +options, but this may change in future. Option processing halts at the +sequence --, so the desired value can be expressed +safely using +default_value -- -1 + + + + + +In many cases it would be useful to calculate default values using +some global preferences, for example: + + +cdl_option CYGIMP_LIBC_STRING_PREFER_SMALL_TO_FAST { + … + default_value CYGGLO_CODESIZE > CYGGLO_SPEED +} + + +Such global preference options do not yet exist, but are likely to be +added in a future version. + + + + + +For options with the booldata flavor the current syntax does not allow +the default values of the enabled flag and the value to be controlled +separately. Functionality to permit this may be added in a future +release. + + + + + +Example + +cdl_option CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT { + display "Include GDB multi-threading debug support" + requires CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT + default_value CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT + description " + This option enables some extra HAL code which is needed + to support multi-threaded source level debugging." +} + + + +See Also + +Properties &calculated;, +&flavor; and +&legal-values;. + + + + + + + + + + +&define; + + + +Property &define; +Specify additional #define symbols that +should go into the owning package's configuration header file. + + + + +cdl_option <name> { + define [-file=<filename>] [-format=<format>] <symbol> + … +} + + + +Description + +Normally the configuration system generates a single +#define for each option that is active and enabled, +with the defined symbol being the name of the option. These +#define's go to the package's own configuration +header file, for example pkgconf/kernel.h +for kernel configuration options. For the majority of options this is +sufficient. Sometimes it is useful to have more control over which +#define's get generated. + + +The &define; property can be used to generate an addition +#define if the option is both active and enabled, +for example: + + +cdl_option CYGNUM_LIBC_STDIO_FOPEN_MAX { + … + define FOPEN_MAX +} + + +If this option is given the value 40 then the following +#define's will be generated in the configuration +header pkgconf/libc.h: + + +#define CYGNUM_LIBC_STDIO_FOPEN_MAX 40 +#define FOPEN_MAX 40 + + +The default #define can be suppressed if desired +using the &no-define; property. This is useful if the symbol should +only be defined in +pkgconf/system.h and not in +the package's own configuration header file. The value that will be +used for this #define is the same as for the +default one, and depends on the option's flavor as follows: + + + + +flavor none + +Options with this flavor are always enabled and have no value, so the +constant 1 will be used. + + +flavor bool + +If the option is disabled then no #define will be +generated. Otherwise the constant 1 will be used. + + +flavor booldata + +If the option is disabled then no #define will be +generated. Otherwise the option's current value will be used. + + +flavor data + +The option's current value will be used. + + + + + +For active options with the data flavor, and for +active and enabled options with the booldata +flavor, either one or two #define's will be +generated. These take the following forms: + + +#define <symbol> <value> +#define <symbol>_<value> + + +For the first #define it is possible to control the +format used for the value using a +-format=<format> option. For example, the +following can be used to output some configuration data as a C string: + + +cdl_option <name> { + … + define -format="\\\"%s\\\"" <symbol> +} + + +The implementation of this facility involves concatenating the +Tcl command format, the format string, and the +string representation of the option's value, and evaluating this in a +Tcl interpreter. Therefore the format string will be processed twice +by a Tcl parser, and appropriate care has to be taken with quoting. + + +The second #define will be generated only if is a +valid C preprocessor macro symbol. By default the symbols generated by +&define; properties will end up in the package's own configuration +header file. The -file option can be used to +specify an alternative destination. At the time of writing the only +valid alternative definition is -file=system.h, +which will send the output to the global configuration header file +pkgconf/system.h. + + + +Care has to be taken with the -format option. +Because the Tcl interpreter's format command is +used, this property is subject to any problems with the implementation +of this in the Tcl library. Generally there should be no problems with +string data or with integers up to 32 bits, but there may well be +problems if 64-bit data is involved. This issue may be addressed in a +future release. + + + + +Example + +cdl_component CYG_HAL_STARTUP { + display "Startup type" + flavor data + legal_values {"RAM" "ROM" } + default_value {"RAM"} + no_define + define -file=system.h CYG_HAL_STARTUP + … +} + + + +See Also + +Properties &define-format;, +&define-header;, +&define-proc;, +&if-define; and +&no-define;. + + + + + + + + + + +&define-format; + + + +Property &define-format; +Control how an option's value will appear in the +configuration header file. + + + + +cdl_option <name> { + define_format <format string> + … +} + + + +Description + +For active options with the data flavor, and for +active and enabled options with the booldata +flavor, the configuration tools will normally generate two +#define's in the package's configuration header +file. These take the following forms: + + +#define <name> <value> +#define <name>_<value> + + +The &define-format; property can be used to control exactly what +appears as the value for the first of these +#define's. For example, the following can be used +to output some configuration data as a C string: + + +cdl_option <name> { + … + define -format="\\\"%s\\\"" <symbol> +} + + +The implementation of &define-format; involves concatenating the Tcl +command format, the format string, and the string +representation of the option's value, and evaluating this in a Tcl +interpreter. Therefore the format string will be processed twice by a +Tcl parser, and appropriate care has to be taken with quoting. + + +The second #define will be generated only if is a +valid C preprocessor macro symbol, and is not affected by the +&define-format; property. Also, the property is only relevant for +options with the data or +booldata flavor, and cannot be used in +conjunction with the &no-define; property since it makes no sense to +specify the format if no #define is generated. + + + +Because the Tcl interpreter's format command is +used, this property is subject to any problems with the implementation +of this in the Tcl library. Generally there should be no problems with +string data or with integers up to 32 bits, but there may well be +problems if 64-bit data is involved. This issue may be addressed in a +future release. + + + + + +Example + +cdl_option CYGNUM_UITRON_VER_ID { + display "OS identification" + flavor data + legal_values 0 to 0xFFFF + default_value 0 + define_format "0x%04x" + description " + This value is returned in the 'id' + field of the T_VER structure in + response to a get_ver() system call." +} + + + +See Also + +Properties &define;, +&define-header;, +&define-proc;, +&if-define; and +&no-define;. + + + + + + + + + + +&define-header; + + + +Property &define-header; +Specify the configuration header file that +will be generated for a given package. + + + + +cdl_package <name> { + define_header <file name> + … +} + + + +Description + +When the configuration tools generate a build tree, one of the steps +is to output each package's configuration data to a header file. For +example the kernel's configuration data gets output to +pkgconf/kernel.h. This allows +each package's source code to #include the +appropriate header file and adapt to the choices made by the user. + + +By default the configuration tools will synthesize a file name from +the package name. This involves removing any prefix such as +CYGPKG_, up to and including the first underscore, +and then converting the remainder of the name to lower case. In some +cases it may be desirable to use a different header file, for example +an existing package may have been ported to &eCos; and the source code +may already #include a particular file for +configuration data. In such cases a &define-header; property can be +used to specify an alternative filename. + + +The &define-header; property can only be used in the body of a +&cdl-package; command. It applies to a package as a whole and cannot +be used at a finer grain. The name specified in a &define-header; +property will always be interpreted as relative to the +include/pkgconf sub-directory +of the install tree. + + + +For hardware-specific packages such as device drivers and HAL +packages, the current scheme of generating a configuration header file +name based on the package name may be abandoned. Instead all hardware +packages would send their configuration data to a single header file, +pkgconf/hardware.h. This would +make it easier for code to obtain details of the current hardware, but +obviously there are compatibility issues. For now it is recommended +that all hardware packages specify their configuration header file +explicitly. + + + + +Example + +cdl_package CYGPKG_HAL_ARM { + display "ARM architecture" + parent CYGPKG_HAL + hardware + include_dir cyg/hal + define_header hal_arm.h + … +} + + + +See Also + +Properties &define;, +&define-format;, +&define-proc;, +&if-define;, +&no-define; and +&hardware;, + + + + + + + + + + +&define-proc; + + + +Property &define-proc; +Use a fragment of Tcl code to output additional data to +configuration header files. + + + + +cdl_option <name> { + define_proc <Tcl script> + … +} + + + +Description + +For most configuration options it is sufficient to have an entry in +the configuration header file of the form: + + +#define <name> <value> + + +In some cases it is desirable to perform some more complicated +processing when generating a configuration header file. There are a +number of CDL properties for this, including &define-format; and +&if-define;. The most flexible is &define-proc;: this allows the +component writer to specify a Tcl script that gets invoked whenever +the configuration system generates the header file for the owning +package. The script can output anything to the header file, for +example it could generate a C data structure based on various +configuration values. + + +At the point that the &define-proc; script is invoked there will be +two channels to open files, accessible via Tcl variables: +cdl_header is a channel to the current package's +own header file for example +pkgconf/kernel.h; +cdl_system_header is a channel to the global +configuration file +pkgconf/system.h. A typical +&define-proc; script will use the puts command to +output data to one of these channels. + + +&define-proc; properties only take effect if the current option is +active and enabled. The default behavior of the configuration system +for an option with the bool flavor corresponds to +the following &define-proc;: + + + cdl_option XXX { + … + define_proc { + puts $cdl_header "#define XXX 1" + } +} + + + +In the current implementation it is not possible for a &define-proc; +property to examine the current values of various configuration +options and adapt accordingly. This is a major limitation, and will be +addressed in future versions of the configuration tools. + + + + + +Example + +cdl_package CYGPKG_HAL_ARM_PID { + display "ARM PID evaluation board" + parent CYGPKG_HAL_ARM + define_header hal_arm_pid.h + include_dir cyg/hal + hardware + + define_proc { + puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H <pkgconf/hal_arm.h>" + puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H <pkgconf/hal_arm_pid.h>" + puts $::cdl_header "" + puts $::cdl_header "#define HAL_PLATFORM_CPU \"ARM 7TDMI\"" + puts $::cdl_header "#define HAL_PLATFORM_BOARD \"PID\"" + puts $::cdl_header "#define HAL_PLATFORM_EXTRA \"\"" + puts $::cdl_header "" + } + … +} + + + +See Also + +Properties &define;, +&define-format;, +&define-header;, +&if-define; and +&no-define;. + + + + + + + + + + +&description; + + + +Property &description; +Provide a textual description for an option. + + + + +cdl_option <name> { + description <text> + … +} + + + +Description + +Users can only be expected to manipulate configuration options +sensibly if they are given sufficient information about these options. +There are three properties which serve to explain an option in plain +text: the &display; property gives a textual alias for an option, +which is usually more comprehensible than something like +CYGPKG_LIBC_TIME_ZONES; the &description; property +gives a longer description, typically a paragraph or so; the &doc; +property specifies the location of additional on-line documentation +related to a configuration option. In the context of a graphical tool +the &display; string will be the primary way for users to identify +configuration options; the &description; paragraph will be visible +whenever the option is selected; the on-line documentation will only +be accessed when the user explicitly requests it. + + +At present there is no way of providing any sort of formatting mark-up +in a description. It is possible that future versions of the +configuration tools will provide some control over the way the +description text gets rendered. + + + +Example + +cdl_option CYGDBG_INFRA_DEBUG_TRACE_MESSAGE { + display "Use trace text" + default_value 1 + description " + All trace calls within eCos contain a text message + which should give some information about the circumstances. + These text messages will end up being embedded in the + application image and hence there is a significant penalty + in terms of image size. + It is possible to suppress the use of these messages by + disabling this option. + This results in smaller code size, but there is less + human-readable information available in the trace output, + possibly only filenames and line numbers." +} + + + +See Also + +Properties &display; and +&doc;. + + + + + + + + + + +&display; + + + +Property &display; +Provide a short string describing this option. + + + + +cdl_option <name> { + display <string> + … +} + + + +Description + +Users can only be expected to manipulate configuration options +sensibly if they are given sufficient information about these options. +There are three properties which serve to explain an option in plain +text: the &display; property gives a textual alias for an option, +which is usually more comprehensible than something like +CYGPKG_LIBC_TIME_ZONES; the &description; property +gives a longer description, typically a paragraph or so; the &doc; +property specifies the location of additional on-line documentation +related to a configuration option. In the context of a graphical tool +the &display; string will be the primary way for users to identify +configuration options; the &description; paragraph will be visible +whenever the option is selected; the on-line documentation will only +be accessed when the user explicitly requests it. + + + +Example + +cdl_option CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE { + display "Message box queue size" + flavor data + legal_values 1 to 65535 + default_value 10 + description " + This configuration option controls the number of messages + that can be queued in a message box before a non-blocking + put() operation will fail or a blocking put() operation will + block. The cost in memory is one pointer per message box for + each possible message." +} + + + +See Also + +Properties &description; and +&doc;. + + + + + + + + + + +&doc; + + + +Property &doc; +The location of online-documentation for a configuration option. + + + + +cdl_option <name> { + doc <URL;> + … +} + + + +Description + +Users can only be expected to manipulate configuration options +sensibly if they are given sufficient information about these options. +There are three properties which serve to explain an option in plain +text: the &display; property gives a textual alias for an option, +which is usually more comprehensible than something like +CYGPKG_LIBC_TIME_ZONES; the &description; property +gives a longer description, typically a paragraph or so; the &doc; +property specifies the location of additional on-line documentation +related to a configuration option. In the context of a graphical tool +the &display; string will be the primary way for users to identify +configuration options; the &description; paragraph will be visible +whenever the option is selected; the on-line documentation will only +be accessed when the user explicitly requests it. + + +The documentation may be an absolute URL, but more generally the +on-line documentation will be shipped with the package and can be +accessed via a relative URL. If the package follows the directory layout conventions then +the configuration tools will search for the specified html file +first in the doc subdirectory +of the package, then relative to the package directory itself. The URL +may contain a # character to specify an anchor +within a page. + + + +At the time of writing the &eCos; packages in the standard +distribution do not conform to the directory layout conventions when +it comes to the documentation. Instead of organizing the documentation +on a per-package basis and placing it in the corresponding +doc sub-directories, all the +documentation is kept in a central location. This should get addressed +in a future release of the system. Third party component writers +should follow the layout conventions. + + + + +Example + +cdl_package CYGPKG_KERNEL { + display "eCos kernel" + doc ref/ecos-ref.4.html + include_dir cyg/kernel + description " + This package contains the core functionality of the eCos + kernel. It relies on functionality provided by various HAL + packages and by the eCos infrastructure. In turn the eCos + kernel provides support for other packages such as the device + drivers and the uITRON compatibility layer." + … +} + + + +See Also + +Properties &description; and +&display;. + + + + + + + + + + +&flavor; + + + +Property &flavor; +Specify the nature of a configuration option. + + + + +cdl_option <name> { + flavor <flavor> + … +} + + + +Description + +The state of a &CDL; configuration option is a somewhat complicated +concept. This state determines what happens when a build tree is +generated: it controls what files get built and what +#define's end up in configuration header files. The +state also controls the values used during expression evaluation. The +key concepts are: + + + +An option may or may not be loaded into the current configuration. +However it is still possible for packages to reference options which +are not loaded in a &requires; constraint or other expression. If an +option is not loaded then it will have no direct effect on the build +process, and 0 will be used for expression +evaluation. + + + +Even if an option is loaded it may still be inactive. Usually this is +controlled by the option's location in the configuration hierarchy. If +an option's parent is active and enabled then the option will normally +be active. If the parent is either inactive or disabled then the +option will be inactive. For example, if kernel timeslicing is diabled +then the option CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS +is irrelevant and must have no effect. The &active-if; property can be +used to specify additional constraints. If an option is inactive then +it will have no direct effect on the build process, in other words it +will not cause any files to get built or #define's +to be generated. For the purposes of expression evaluation an inactive +option has a value of 0. + + + +An option may be enabled or disabled. Most options are boolean in +nature, for example a particular function may get inlined or it may +involve a full procedure call. If an option is disabled then it has no +direct effect on the build process, and for the purposes of expression +evaluation it has a value of 0. + + +An option may also have additional data associated with it, for +example a numerical value used to control the size of an array. + + + +Most options are boolean in nature and do not have any additional +associated data. For some options only the data part makes sense and +users should be unable to manipulate the enabled/disabled part of the +state. For a comparatively small number of options it makes sense to +have the ability to disable that option or to enable it and associate +data as well. Finally, when constructing an option hierarchy it is +occasionally useful to have entities which serve only as placeholders. +The &flavor; property can be used to control all this. There are four +possible values. It should be noted that the active or inactive state +of an option takes priority over the flavor: if an option is inactive +then no #define's will be generated and any +build-related properties such as &compile; will be ignored. + + + + +flavor none + +The none is intended primarily for placeholder +components in the hierarchy, although it can be used for other +purposes. Options with this flavor are always enabled and do not have +any additional data associated with them, so there is no way for users +to modify the option. For the purposes of expression evaluation an +option with flavor none always has the value +1. Normal #define processing +will take place, so typically a single #define will +be generated using the option name and a value of +1. Similarly build-related properties such as +&compile; will take effect. + + +flavor bool + +Boolean options can be either enabled or disabled, and there is no +additional data associated with them. If a boolean option is disabled +then no #define will be generated and any +build-related properties such as &compile; will be ignored. For the +purposes of expression evaluation a disabled option has the value +0. If a boolean option is enabled then normal +#define processing will take place, all +build-related properties take effect, and the option's value will be +1. + + +flavor data + +Options with this flavor are always enabled, and have some additional +data associated with them which can be edited by the user. This data +can be any sequence of characters, although in practice the +&legal-values; property will often be used to impose constraints. In +appropriate contexts such as expressions the configuration tools will +attempt to interpret the data as integer or floating point numbers. +Since an option with the data flavor cannot be +disabled, normal #define processing takes place and +the data will be used for the value. Similarly all build-related +properties take effect, and the option's value for the purposes of +expression evaluation is the data. + + +flavor booldata + +This combines the bool and data +flavors. The option may be enabled or disabled, and in addition the +option has some associated data. If the option is disabled then no +#define will be generated, the build-related +properties have no effect, and for the purposes of expression +evaluation the option's value is 0. If the option +is enabled then a #define will be generated using +the data as the value, all build-related properties take effect, and +the option's value for the purposes of expression evaluation is the +data. If 0 is legal data then it is not possible to +distinguish this case from the option being disabled or inactive. + + + + + +Options and components have the bool flavor by +default, but this can be changed as desired. Packages always have the +booldata flavor, and this cannot be changed. +Interfaces have the data flavor by default, since +the value of an interface is a count of the number of active and +enabled interfaces, but they can be given the bool +or booldata flavors. + + + + +The expression syntax needs to be extended to allow the loaded, +active, enabled and data aspects of an option's state to be examined +individually. This would allow component writers to distinguish +between a disabled booldata option and an enabled +one which has a value of 0. Such an enhancement to +the expression syntax may also prove useful in other circumstances. + + + + + +Example + + +cdl_component CYGPKG_LIBM_COMPATIBILITY { + + cdl_component CYGNUM_LIBM_COMPATIBILITY { + flavor booldata + … + + cdl_option CYGNUM_LIBM_COMPAT_DEFAULT { + flavor data + … + } + } + + … +} + +cdl_component CYGPKG_LIBM_TRACE { + flavor bool + … +} + + + +See Also + +Properties &calculated;, +&default-value; and +&legal-values;, + + + + + + + + + + +&hardware; + + + +Property &hardware; +Specify that a package is tied to specific hardware. + + + + +cdl_option <name> { + active_if <condition> + … +} + + + +Description + +Some packages such as device drivers and HAL packages are +hardware-specific, and generally it makes no sense to add such +packages to a configuration unless the corresponding hardware is +present on your target system. Typically hardware package selection +happens automatically when you select your target. The &hardware; +property can be used in the body of a &cdl-package; command to +indicate that the package is hardware-specific. + + + + +At the time of writing the &hardware; property is largely ignored by +the configuration tools, but this may change in future. Amongst other +possible changes, for hardware-specific packages such as device +drivers and HAL packages, the current scheme of generating a +configuration header file name based purely on the package name may be +abandoned. Instead all hardware packages would send their +configuration data to a single header file, pkgconf/hardware.h. This would make it +easier for code to obtain details of the current hardware, but +obviously there are compatibility issues. For now it is recommended +that all hardware packages specify their configuration header file +explicitly. + + + + +Example + +cdl_package CYGPKG_HAL_ARM { + display "ARM architecture" + parent CYGPKG_HAL + hardware + include_dir cyg/hal + define_header hal_arm.h + … +} + + + +See Also + +Property &define-header;, and +command &cdl-package;. + + + + + + + + + + +&if-define; + + + +Property &if-define; +Output a common preprocessor construct to a configuration +header file. + + + + +cdl_option <name> { + if_define [-file=<filename>] <symbol1> <symbol2> + … +} + + + +Description + +The purpose of the &if-define; property is best explained by an +example. Suppose you want finer-grained control over assertions, say +on a per-package or even a per-file basis rather than globally. The +assertion macros can be defined by an exported header file in an +infrastructure package, using code like the following: + + +#ifdef CYGDBG_USE_ASSERTS +# define CYG_ASSERT( _bool_, _msg_ ) \ + CYG_MACRO_START \ + if ( ! ( _bool_ ) ) \ + CYG_ASSERT_DOCALL( _msg_ ); \ + CYG_MACRO_END +#else +# define CYG_ASSERT( _bool_, _msg_ ) CYG_EMPTY_STATEMENT +#endif + + +Assuming this header file is #include'd directly or +indirectly by any code which may need to be built with assertions +enabled, the challenge is now to control whether or not +CYGDBG_USE_ASSERTS is defined for any given source +file. This is the purpose of the &if-define; property: + + +cdl_option CYGDBG_KERNEL_USE_ASSERTS { + … + if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS + requires CYGDBG_INFRA_ASSERTION_SUPPORT +} + + +If this option is active and enabled then the kernel's configuration +header file would end up containing the following: + + +#ifdef CYGSRC_KERNEL +# define CYGDBG_USE_ASSERTS 1 +#endif + + +Kernel source code can now begin with the following construct: + + +#define CYGSRC_KERNEL 1 +#include <pkgconf/kernel.h> +#include <cyg/infra/cyg_ass.h> + + +The configuration option only affects kernel source code, assuming +nothing else #define's the symbol +CYGSRC_KERNEL. If the per-package assertion option +is disabled then CYGDBG_USE_ASSERTS will not get +defined. If the option is enabled then +CYGDBG_USE_ASSERTS will get defined and assertions +will be enabled for the kernel sources. It is possible to use the same +mechanism for other facilities such as tracing, and to apply it at a +finer grain such as individual source files by having multiple options +with &if-define; properties and multiple symbols such as +CYGSRC_KERNEL_SCHED_BITMAP_CXX. + + +The &if-define; property takes two arguments, both of which must be +valid C preprocessor symbols. If the current option is active and +enabled then three lines will be output to the configuration header +file: + + +#ifdef <symbol1> +# define <symbol2> +#endif + + +If the option is inactive or disabled then these lines will not be +output. By default the current package's configuration header file +will be used, but it is possible to specify an alternative destination +using a -file option. At present the only +legitimate alternative destination is system.h, the +global configuration header. &if-define; processing happens in +addition to, not instead of, the normal #define +processing or the handling of other header-file related properties. + + + +The infrastructure in the current &eCos; release does not yet work +this way. In future it may do so, and the intention is that suitable +configuration options get generated semi-automatically by the +configuration system rather than having to be defined explicitly. + + + + +As an alternative to changing the configuration, updating the build +tree, and so on, it is possible to enable assertions by editing a +source file directly, for example: + + +#define CYGSRC_KERNEL 1 +#define CYGDBG_USE_ASSERTS 1 +#include <pkgconf/kernel.h> +#include <cyg/infra/cyg_ass.h> + + +The assertion header file does not care whether +CYGDBG_USE_ASSERTS is #define'd +via a configuration option or by explicit code. This technique can be +useful to component writers when debugging their source code, although +care has to be taken to remove any such #define's +later on. + + + + + +Example + +cdl_option CYGDBG_KERNEL_USE_ASSERTS { + display "Assertions in the kernel package" + … + if_define CYGSRC_KERNEL CYGDBG_USE_ASSERTS + requires CYGDBG_INFRA_ASSERTION_SUPPORT +} + + + +See Also + +Properties &define;, +&define-format;, +&define-header;, +&define-proc; and +&no-define;. + + + + + + + + + + +&implements; + + + +Property &implements; +Enabling this option provides one instance of a more +general interface. + + + + +cdl_option <name> { + implements <interface> + … +} + + + +Description + +The &CDL; interface concept provides an abstraction mechanism that can +be useful in many different circumstances. Essentially an interface is +a calculated option whose value is the number of active and enabled +options which implement that interface. For example the interface +CYGINT_KERNEL_SCHEDULER has a value corresponding +to the number of schedulers in the system, typically just one. + + +The &implements; property takes a single argument, which should be the +name of an interface. This interface may be defined in the same +package as the implementor or in some other package. In the latter +case it may sometimes be appropriate for the implementor or the +implementor's package to have a &requires; property for the package +containing the interface. An option may contain multiple &implements; +properties. It is possible for an option to implement a given +interface multiple times, and on occasion this is actually useful. + + + +Example + +cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE { + display "Multi-level queue scheduler" + default_value 1 + implements CYGINT_KERNEL_SCHEDULER + … +} + + + +See Also + +Command &cdl-interface;. + + + + + + + + + + +&include-dir; + + + +Property &include-dir; +Specify the desired location of a package's exported +header files in the install tree. + + + + +cdl_package <name> { + include_dir <sub-directory> + … +} + + + +Description + +Most packages export one or more header files defining their public +interface. For example the C library exports header files such as +stdio.h and +ctype.h. +If the package follows the directory +layout conventions then the exported header files will normally +be found in the package's +include sub-directory. +Alternatively the &include-files; property can be used to specify +which header files should be exported. + + +By default a package's exported header files will be copied to +the include sub-directory of +the install tree. This is correct for packages like the C library +because that is the correct location for files such as +stdio.h. However to reduce the +probability of name clashes it is desirable for packages to use +different sub-directories, for example infrastructure header files get +copied to include/cyg/infra +rather than to the top-level +include directory itself. + + +It would be possible to replicate these sub-directories in each +package's source tree, such that the infrastructure header file +sources lived in +include/cyg/infra in the source +tree as well as in the install tree. This would make things more +difficult for the package developers. Instead it is possible to +specify the desired install tree sub-directory using an &include-dir; +property, for example include_dir cyg/infra. + + +The &include-dir; property can only be used in the body of a +&cdl-package; command, since it applies to all of the header files +exported by a package, and only one &include-dir; property can be +used. If there is no &include-dir; property then exported header files +will end up in the top-level include +directory of the install tree. + + + +Example + +cdl_package CYGPKG_INFRA { + display "Infrastructure" + include_dir cyg/infra + description " + Common types and useful macros. + Tracing and assertion facilities. + Package startup options." + … +} + + + +See Also + +Property &include-files;, and +command &cdl-package;. + + + + + + + + + + +&include-files; + + + +Property &include-files; +List the header files that are exported by a package. + + + + +cdl_package <name> { + include_files <file1> … + … +} + + + +Description + +Most packages export one or more header files defining their public +interface. For example the C library exports header files such as +stdio.h and +ctype.h. +If the package follows the directory +layout conventions then the exported header files will normally +be found in the package's +include sub-directory. For +packages which do not follow these conventions, typically simple ones +for which a complicated sub-directory hierarchy is undesirable, there +has to be an alternative way of specifying which header file or files +define the public interface. The &include-files; property provides +support for this. + + +By default, if a package does not have an +include subdirectory and it +does not have an &include-files; property then all files with a suffix +of .h, .hxx, +.inl or .inc will be treated as +public header files. However some of these may be private files +containing implementation details. If there is an +&include-files; property then only the files listed in that property +will be exported. + + +If a package should not export any header files but does contain +private implementation headers, an &include-files; property with no +arguments should be used. + + + +Example + +cdl_package <SOME_PACKAGE> { + … + include_dir <some directory> + include_files interface.h +} + +cdl_package <ANOTHER_PACKAGE> { + … + include_files +} + + + +See Also + +Property &include-dir;, and +command &cdl-package;. + + + + + + + + + + +&legal-values; + + + +Property &legal-values; +Impose constraints on the possible values for an option. + + + + +cdl_option <name> { + legal_values <list expression> + … +} + + + +Description + +Options with the data or +booldata flavors can have an arbitrary sequence of +characters as their data. In nearly all cases some restrictions have +to be imposed, for example the data should correspond to a number +within a certain range, or it should be one of a small number of +constants. The &legal-values; property can be used to impose such +constraints. The arguments to the property should be a &CDL; list +expression, see for the +syntactic details. Common examples include: + + + legal_values 0 to 0x7fff + legal_values 9600 19200 38400 + legal_values { "RAM" "ROM" } + + +The &legal-values; property can only be used for options with the +data or booldata flavors, since +it makes little sense to further constrain the legal values of a +boolean option. An option can have at most one &legal-values; +property. + + + + +If the first entry in a &legal-values; list expression is a negative +number, for example +legal_values -1 to 1 then this can +be misinterpreted as an option instead of as part of the expression. +Currently the &legal-values; property does not take any options, but +this may change in future. Option processing halts at the sequence +--, so the desired range can be expressed safely +using legal_values -- -1 to 1 + + + + + +Architectural HAL packages should provide constants which can be used +in &legal-values; list expressions. For example it should be possible +to specify a numeric range such as +0 to CYGARC_MAXINT, rather than +hard-wiring numbers such as 0x7fffffff which may +not be valid on all targets. Current HAL packages do not define such +constants. + + + + + +The &legal-values; property is restricted mainly to numerical ranges +and simple enumerations, and cannot cope with more complicated data +items. Future versions of the configuration system will provide +additional data validation facilities, for example a +check_proc property which specifies a Tcl script +that can be used to perform the validation. + + + + +Example + +cdl_option CYGNUM_LIBC_TIME_STD_DEFAULT_OFFSET { + display "Default Standard Time offset" + flavor data + legal_values -- -90000 to 90000 + default_value -- 0 + description " + This option controls the offset from UTC in + seconds when in local Standard Time. This + value can be positive or negative. It + can also be set at run time using the + cyg_libc_time_setzoneoffsets() function." +} + + + +See Also + +Properties &calculated;, +&default-value;, and +&flavor;. + + + + + + + + + + +&library; + + + +Property &library; +Specify which library should contain the object files +generated by building this package. + + + + +cdl_package <name> { + library <library name> + … +} + + + +Description + +By default all object files that get built for all packages end up in +a single library, libtarget.a. This makes things +easier for the typical application developer because it is only +necessary to link with a single library, rather than with separate +libraries for each package. It is possible to specify an alternative +library for specific files as an option to the &compile; and +&make-object; properties, and there is one library libextras.a which serves a +specific purpose in the build system. The &library; property allows an +alternative library to be specified for all the object files that will +be generated for a given package. + + +The use of the &library; property should be avoided, since it makes +things more difficult for application developers. The property is +intended only for special cases, for example if there are legal +objections to mingling object files from different packages in a +single library. It could also be used to work around name clash +problems if two packages happen to define an exported symbol with the +same name, but any attempt to use multiple libraries in this way is +error-prone and should be avoided. + + +The &library; property takes a single argument, the name of a library, +which should follow the standard naming convention of +lib<something>.a. A &library; property can +only occur in the body of a &cdl-package; command and applies to all +object files generated for that package (except where explicitly +overwritten with a -library= option to one of the +build-related properties). A &cdl-package; body can contain at most +one &library; property. + + + +Example + +cdl_package <SOME_PACKAGE> { + … + library libSomePackage.a +} + + + +See Also + +Properties &compile;, +&make;, and +&make-object;, +command &cdl-package;. + + + + + + + + + + +&make; + + + +Property &make; +Define an additional custom build step associated with an +option, resulting in a target that should not go directly into a library. + + + + +cdl_option <name> { + make [-priority=<pri>] { + <custom build step> + } + … +} + + + +Description + +When building an &eCos; configuration the primary target is a single +library, libtarget.a. In some cases it is +necessary to build some additional targets. For example architectural +HAL packages typically build a linker script and some start-up code. +Such additional targets can be specified by a &make; property. Any +option can have one or more &make; properties, although typically such +properties only occur in the body of a &cdl-package; command. + + +The &make; property takes a single argument, which resembles a +makefile rule: it consists of a target, a list of dependencies, and +one or more commands that should be executed. However the argument is +not a makefile fragment, and custom build steps may get executed in +build environments that do not involve make. For full details of +custom build steps see . + + + +The exact syntax and limitations of custom build steps have not yet +been finalized, and are subject to change in future versions of the +configuration tools. + + + +The &make; property takes an optional priority argument indicating the +order in which build steps take place. This priority complements the +dependency list, and avoids problems with packages needing to know +details of custom build steps in other packages (which may change +between releases). The defined order is: + + + +Priority 0 + +The header files exported by the current set of packages are copied +to the appropriate places in the +include subdirectory of the +install tree. Any unnecessary copies are avoided, to prevent rebuilds +of package and application source modules caused by header file dependencies. + + +A possible future enhancement of the build system may result in the +build and install trees being updated automatically if there has been +a change to the ecos.ecc configuration savefile. + + + +Priority 100 + +All files specified in &compile; properties will get built, producing +the corresponding object files. In addition any custom build steps +defined by &make-object; properties get executed, unless there is +a -priority= option. + + + +Priority 200 + +The libraries now get built using the appropriate object files. + + + +Priority 300 + +Any custom build steps specified by &make; properties now get +executed, unless the priority for a particular build step is changed +from its default. + + + + + +For example, if a custom build step needs to take place before any of +the normal source files get compiled then it should be given a +priority somewhere between 0 and 100. If a custom build step involves +post-processing an object file prior to its incorporation into a +library then a priority between 100 and 200 should be used. + + + + +Example + +cdl_package CYGPKG_HAL_MN10300_AM33 { + display "MN10300 AM33 variant" + parent CYGPKG_HAL_MN10300 + implements CYGINT_HAL_MN10300_VARIANT + hardware + include_dir cyg/hal + define_header hal_mn10300_am33.h + description " + The MN10300 AM33 variant HAL package provides generic + support for this processor architecture. It is also + necessary to select a specific target platform HAL + package." + + make { + <PREFIX>/lib/target.ld: <PACKAGE>/src/mn10300_am33.ld + $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $< + @echo $@ ": \\" > $(notdir $@).deps + @tail +2 target.tmp >> $(notdir $@).deps + @echo >> $(notdir $@).deps + @rm target.tmp + } +} + + + +See Also + +Properties compile, +make_object and +library. + + + + + + + + + + +&make-object; + + + +Property &make-object; +Define a custom build step, resulting in an object file +that should go into a library. + + + + +cdl_option <name> { + make_object [-library=<library>] [-priority=<pri>] { + <custom build step> + } + … +} + + + +Description + +When building an &eCos; configuration the primary target is a single +library, libtarget.a. Most of the object files +which go into this library will be generated as a result of &compile; +properties. Occasionally it may be necessary to have special build +steps for a given object file, and this can be achieved with a +&make-object; property. The use of this property should be avoided +whenever possible because it greatly increases the risk of portability +problems, both on the host side because of possible problems with the +tools, and on the target side because a custom build step may not +allow adequately for the wide variety of architectures supported by +&eCos;. + + +The &make-object; property takes a single argument, which resembles a +makefile rule: it consists of a target, a list of dependencies, and +one or more commands that should be executed. The target should be an +object file. However the &make-object; argument is not a makefile +fragment, and custom build steps may get executed in build +environments that do not involve make. For full details of custom +build steps see . + + + +The exact syntax and limitations of custom build steps have not yet +been finalized, and may change in future versions of the +configuration tools. + + + +The &make-object; property takes an optional library argument. If no +library is specified then the default library for the current package +will be used, which will be libtarget.a unless +the &cdl-package; command contains a &library; property. + + +The &make-object; property also takes an optional priority argument +indicating the order in which build steps take place. This priority +complements the dependency list, and avoids problems with packages +needing to know details of custom build steps in other packages (which +may change between releases). The defined order is: + + + +Priority 0 + +The header files exported by the current set of packages are copied +to the appropriate places in the +include subdirectory of the +install tree. Any unnecessary copies are avoided, to prevent rebuilds +of package and application source modules caused by header file dependencies. + + +A possible future enhancement of the build system may result in the +build and install trees being updated automatically if there has been +a change to the ecos.ecc configuration savefile. + + + +Priority 100 + +All files specified in &compile; properties will get built, producing +the corresponding object files. In addition any custom build steps +defined by &make-object; properties get executed, unless there is a +-priority= option. + + + +Priority 200 + +The libraries now get built using the appropriate object files. + + + +Priority 300 + +Any custom build steps specified by &make; properties now get +executed, unless the priority for a particular build step is changed +from its default. + + + + + +For example, if a custom build step needs to take place before any of +the normal source files get compiled then it should be given a +priority somewhere between 0 and 100. If a custom build step involves +post-processing an object file prior to its incorporation into a +library then a priority between 100 and 200 should be used. It is not +sensible to have a priority above 200, since that would imply building +an additional object file for a library that has already been created. + + + +Example + +cdl_option XXX { + … + make_object { + parser.o: parser.y + yacc $< + $(CC) $(CFLAGS) -o $@ y.tab.c + } +} + + + +See Also + +Properties compile, +make and +library. + + + + + + + + + + +&no-define; + + + +Property &no-define; +Suppress the normal generation of a preprocessor +#define symbol in a configuration header file. + + + + +cdl_option <name> { + no_define + … +} + + + +Description + +By default all active and enabled properties result in either one or +two #define'd symbols in the package's +configuration header file, and this is one of the main ways in which +options can affect packages at build-time. It is possible to suppress +the default #define's by specifying a +&no-define; property in the body of an option or other &CDL; entity. +This property takes no arguments and should occur only once in a given +body. + + +The &no-define; property is frequently used in conjunction with one of +the other header-file related properties such as &define;. If one of +the other properties is used to export the required information to a +configuration header file then often there is little point in +exporting the default #define as +well &mdash  in fact there could be a name clash. The +&no-define; property can also be useful if the sole purpose of an +option is to affect which files get built, and the default +#define would never get tested in any source code. +However in such cases the default #define is +mostly harmless and there is little to be gained by suppressing it. + + + + +Example + +cdl_component CYG_HAL_STARTUP { + display "Startup type" + flavor data + legal_values { "RAM" "ROM" } + default_value {"RAM"} + no_define + define -file system.h CYG_HAL_STARTUP + … +} + + + +See Also + +Properties &define;, +&define-format;, +&define-header;, +&define-proc; and +&if-define;. + + + + + + + + + + +&parent; + + + +Property &parent; +Control the location of an option in the configuration hierarchy. + + + + +cdl_option <name> { + parent <component or package> + … +} + + + +Description + +Configuration options live in a hierarchy of packages and components. +By default a given option's position in the hierarchy is a simple +consequence of its position within the CDL scripts. Packages are +generally placed at the top-level of the configuration. Any components +or options that are defined at the same level as the &cdl-package; +command in a package's top-level CDL script are placed immediately +below that package in the hierarchy. Any options or components that +are defined in the body of a &cdl-package; or &cdl-component; command, +or that are read in as a result of processing a component's &script; +property, will be placed immediately below that package or component +in the hierarchy. + + +In some circumstances it is useful to specify an alternative position +in the hierarchy for a given option. For example it is often +convenient to re-parent device driver packages below +CYGPKG_IO in the configuration hierarchy, thus +reducing the number of packages at the top level of the hierarchy and +making navigation easier. The &parent; property can be used to achieve +this. + + +The &parent; property takes a single argument, which should be the +name of a package or component. The body of a &cdl-option; or other +CDL entity can contain at most one &parent; property. + + +Although the &parent; property affects an option's position in the +overall hierarchy and hence whether or not that option is active, a +re-parented option still belongs to the package that defines it. By +default any #define's will be exported to that +package's configuration header file. Any &compile; properties can only +reference source files present in that package, and it is not directly +possible to cause some file in another package to be built by +re-parenting. + + +As a special case, if an empty string is specified for the parent then +the option is placed at the top of the hierarchy, ahead of any +packages which are not explicitly re-parented in this way. This +facility is useful for configuration options such as global +preferences and default compiler flags. + + + + +If an option is re-parented somewhere below another package and that +other package is not actually loaded, the option is an orphan and its +active/inactive state is undefined. In such cases it is a good idea +for the owning package to require the presence of the other one. +Unfortunately this technique does not work if a package as a whole is +reparented below another one that has not been loaded: the package is +orphaned so it may be automatically inactive, and hence any &requires; +properties would have no effect. + + + + + +Example + +cdl_package CYGPKG_HAL_I386 { + display "i386 architecture" + parent CYGPKG_HAL + hardware + include_dir cyg/hal + define_header hal_i386.h + … +} + +cdl_component CYGBLD_GLOBAL_OPTIONS { + display "Global build options" + parent "" + … +} + + + +See Also + +Property &script;, +commands &cdl-component; and +&cdl-package;. + + + + + + + + + + +&requires; + + + +Property &requires; +List constraints that the configuration should satisfy if +a given option is active and enabled.. + + + + +cdl_option <name> { + requires <goal expression> + … +} + + + +Description + +Configuration options are not independent. For example the C library +can provide thread-safe implementations of certain functions, but only +if the kernel is present, if the kernel provides multi-threading, and +if the kernel options related to per-thread data are enabled. It is +possible to express such constraints using &requires; properties. + + +The arguments to a &requires; property should constitute a goal +expression, as described in . +Most goal expressions are relatively simple because the constraints +being described are simple, but complicated expressions can be used +when necessary. The body of an option or other CDL entity can contain +any number of &requires; constraints. If the option is active and +enabled then all these constraints should be satisfied, and any goal +expressions which evaluate to 0 will result in +conflicts being raised. It is possible for users to ignore such +conflicts and attempt to build the current configuration anyway, but +there is no guarantee that anything will work. If an option is +inactive or disabled then its &requires; constraints will be ignored. + + +The configuration system contains an inference engine which can +resolve many types of conflicts automatically. For example, if option +A is enabled and requires an option +B that is currently disabled then the inference +engine may attempt to resolve the conflict by enabling +B. However this will not always be possible, for +example there may be other constraints in the configuration which +force B to be disabled at present, in which case +user intervention is required. + + + +Example + +cdl_component CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_A { + display "Cogent PowerPC serial port A driver" + flavor bool + default_value 0 + requires (CYGIMP_KERNEL_INTERRUPTS_CHAIN || \ + !CYGPKG_IO_SERIAL_POWERPC_COGENT_SERIAL_B) + … +} + + + +See Also + +Property &active-if;. + + + + + + + + + + +&script; + + + +Property &script; +Include additional configuration information from another +CDL script. + + + + +cdl_component <name> { + script <filename> + … +} + + + +Description + +It is possible to define all the configuration options and +sub-components for a given package in a single CDL script, either by +nesting them in the appropriate command bodies, by extensive use of +the &parent; property, or by some combination of these two. However +for large packages this is inconvenient and it is better to split the +raw configuration data over several different files. The &script; +property can be used to achieve this. It takes a single filename as +argument. If the package follows the directory layout conventions then +the configuration tools will look for the specified file in the +cdl sub-directory of the +package, otherwise it will look for the file relative to the package's +top-level directory. + + +The &script; property can only occur in the body of a &cdl-component +command, and only one &script; property per body is allowed. + + + +Example + +cdl_component CYGPKG_UITRON_TASKS { + display "Tasks" + flavor none + description " + uITRON Tasks are the basic blocks of multi-tasking + in the uITRON world; they are threads or lightweight + processes, sharing the address space and the CPU. + They communicate using the primitives outlined above. + Each has a stack, an entry point (a C or C++ function), + and (where appropriate) a scheduling priority." + + script tasks.cdl +} + + + +See Also + +Command &cdl-component;, +and property &parent;. + + + + + + + + \ No newline at end of file diff --git a/host/libcdl/doc/repo.fig b/host/libcdl/doc/repo.fig new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/repo.fig @@ -0,0 +1,63 @@ +#FIG 3.2 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 415 806 5863 806 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 415 806 415 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3366 389 3366 806 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1096 806 1096 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1777 806 1777 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 2458 806 2458 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3138 806 3138 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3819 806 3819 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 4501 806 4501 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 5181 806 5181 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 5863 806 5863 1223 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1096 1641 1096 2058 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 2458 1641 2458 2058 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 2458 2058 2458 2475 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1777 2058 1777 2475 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3138 2058 3138 2475 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 3 + 1777 2058 2685 2058 3138 2058 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 5181 1641 5181 2058 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3819 1641 3819 2058 +4 0 0 100 0 0 12 0.0000 4 171 601 812 1432 compat/\001 +4 0 0 100 0 0 12 0.0000 4 148 432 1607 1432 error/\001 +4 0 0 100 0 0 12 0.0000 4 148 284 2345 1432 hal/\001 +4 0 0 100 0 0 12 0.0000 4 148 420 2912 1432 infra/\001 +4 0 0 100 0 0 12 0.0000 4 148 204 3706 1432 io/\001 +4 0 0 100 0 0 12 0.0000 4 148 522 4274 1432 kernel/\001 +4 0 0 100 0 0 12 0.0000 4 171 714 4955 1432 language/\001 +4 0 0 100 0 0 12 0.0000 4 171 772 5806 1432 templates/\001 +4 0 0 100 0 0 12 0.0000 4 125 545 75 1432 ecos.db\001 +4 0 0 100 0 0 12 0.0000 4 148 511 812 2266 uitron/\001 +4 0 0 100 0 0 12 0.0000 4 148 669 1437 2684 /\001 +4 0 0 100 0 0 12 0.0000 4 148 669 2174 2684 /\001 +4 0 0 100 0 0 12 0.0000 4 148 192 3082 2684 .../\001 +4 0 0 100 0 0 12 0.0000 4 148 136 5124 2266 c/\001 +4 0 0 100 0 0 10 0.0000 4 11 102 3819 2266 ...\001 +4 0 0 100 0 0 13 0.0000 4 195 885 3000 300 packages/\001 diff --git a/host/libcdl/doc/version.fig b/host/libcdl/doc/version.fig new file mode 100644 --- /dev/null +++ b/host/libcdl/doc/version.fig @@ -0,0 +1,23 @@ +#FIG 3.2 +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3000 600 3000 1200 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1800 1200 4200 1200 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 1800 1200 1800 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 4200 1200 4200 1800 +2 1 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 2 + 3000 1200 3000 1800 +4 0 0 100 0 0 14 0.0000 4 180 600 2775 525 kernel/\001 +4 0 0 100 0 0 14 0.0000 4 180 690 1500 2025 current/\001 +4 0 0 100 0 0 14 0.0000 4 180 420 4050 2025 v1.3/\001 +4 0 0 100 0 0 14 0.0000 4 180 525 2775 2025 v1.21/\001 diff --git a/packages/ChangeLog b/packages/ChangeLog --- a/packages/ChangeLog +++ b/packages/ChangeLog @@ -2074,7 +2074,7 @@ 1998-07-23 Bart Veer + + * cdl/posix.cdl: Don't build tests using signals when posix + signals are disabled. + +2002-05-21 Jesper Skov + + * tests/mutex3.c: Added an NA check. + 2002-04-09 Jonathan Larmour * src/signal.cxx (cyg_deliver_signals): Don't assert here for an @@ -919,34 +928,34 @@ 2000-03-24 Nick Garnett + + * doc/uitron.sgml: Fixed dangling xref. + 2002-02-19 Mark Salter * doc/uitron.sgml: Fixed typos and such. @@ -855,7 +859,7 @@ Fri Jul 24 13:02:46 1998 Hugo Tyson // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/arm/flexanet/current/cdl/flexanet_eth_drivers.cdl b/packages/devs/eth/arm/flexanet/current/cdl/flexanet_eth_drivers.cdl --- a/packages/devs/eth/arm/flexanet/current/cdl/flexanet_eth_drivers.cdl +++ b/packages/devs/eth/arm/flexanet/current/cdl/flexanet_eth_drivers.cdl @@ -7,36 +7,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/arm/flexanet/current/include/devs_eth_flexanet.inl b/packages/devs/eth/arm/flexanet/current/include/devs_eth_flexanet.inl --- a/packages/devs/eth/arm/flexanet/current/include/devs_eth_flexanet.inl +++ b/packages/devs/eth/arm/flexanet/current/include/devs_eth_flexanet.inl @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/eth/arm/flexanet/current/src/if_flexanet.c b/packages/devs/eth/arm/flexanet/current/src/if_flexanet.c --- a/packages/devs/eth/arm/flexanet/current/src/if_flexanet.c +++ b/packages/devs/eth/arm/flexanet/current/src/if_flexanet.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/devs/eth/arm/integrator/current/ChangeLog b/packages/devs/eth/arm/integrator/current/ChangeLog --- a/packages/devs/eth/arm/integrator/current/ChangeLog +++ b/packages/devs/eth/arm/integrator/current/ChangeLog @@ -43,7 +43,7 @@ 2000-08-21 Philippe Robin // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/arm/integrator/current/cdl/integrator_eth_drivers.cdl b/packages/devs/eth/arm/integrator/current/cdl/integrator_eth_drivers.cdl --- a/packages/devs/eth/arm/integrator/current/cdl/integrator_eth_drivers.cdl +++ b/packages/devs/eth/arm/integrator/current/cdl/integrator_eth_drivers.cdl @@ -7,36 +7,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/arm/integrator/current/include/devs_eth_arm_integrator_i82559.inl b/packages/devs/eth/arm/integrator/current/include/devs_eth_arm_integrator_i82559.inl --- a/packages/devs/eth/arm/integrator/current/include/devs_eth_arm_integrator_i82559.inl +++ b/packages/devs/eth/arm/integrator/current/include/devs_eth_arm_integrator_i82559.inl @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/eth/arm/iq80310/current/ChangeLog b/packages/devs/eth/arm/iq80310/current/ChangeLog --- a/packages/devs/eth/arm/iq80310/current/ChangeLog +++ b/packages/devs/eth/arm/iq80310/current/ChangeLog @@ -96,7 +96,7 @@ 2000-11-06 Mark Salter // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/arm/nano/current/cdl/nano_eth_drivers.cdl b/packages/devs/eth/arm/nano/current/cdl/nano_eth_drivers.cdl --- a/packages/devs/eth/arm/nano/current/cdl/nano_eth_drivers.cdl +++ b/packages/devs/eth/arm/nano/current/cdl/nano_eth_drivers.cdl @@ -7,36 +7,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/arm/nano/current/include/devs_eth_nano.inl b/packages/devs/eth/arm/nano/current/include/devs_eth_nano.inl --- a/packages/devs/eth/arm/nano/current/include/devs_eth_nano.inl +++ b/packages/devs/eth/arm/nano/current/include/devs_eth_nano.inl @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/eth/cf/current/ChangeLog b/packages/devs/eth/cf/current/ChangeLog --- a/packages/devs/eth/cf/current/ChangeLog +++ b/packages/devs/eth/cf/current/ChangeLog @@ -143,7 +143,7 @@ 2000-07-14 Gary Thomas // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/intel/i21143/current/cdl/intel_i21143_eth_drivers.cdl b/packages/devs/eth/intel/i21143/current/cdl/intel_i21143_eth_drivers.cdl --- a/packages/devs/eth/intel/i21143/current/cdl/intel_i21143_eth_drivers.cdl +++ b/packages/devs/eth/intel/i21143/current/cdl/intel_i21143_eth_drivers.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/intel/i21143/current/src/if_i21143.c b/packages/devs/eth/intel/i21143/current/src/if_i21143.c --- a/packages/devs/eth/intel/i21143/current/src/if_i21143.c +++ b/packages/devs/eth/intel/i21143/current/src/if_i21143.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/devs/eth/intel/i82544/current/ChangeLog b/packages/devs/eth/intel/i82544/current/ChangeLog --- a/packages/devs/eth/intel/i82544/current/ChangeLog +++ b/packages/devs/eth/intel/i82544/current/ChangeLog @@ -66,7 +66,7 @@ 2001-11-27 Nick Garnett // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/mips/upd985xx/current/cdl/upd985xx_eth_drivers.cdl b/packages/devs/eth/mips/upd985xx/current/cdl/upd985xx_eth_drivers.cdl --- a/packages/devs/eth/mips/upd985xx/current/cdl/upd985xx_eth_drivers.cdl +++ b/packages/devs/eth/mips/upd985xx/current/cdl/upd985xx_eth_drivers.cdl @@ -7,36 +7,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/mips/upd985xx/current/include/upd985xx_eth.h b/packages/devs/eth/mips/upd985xx/current/include/upd985xx_eth.h --- a/packages/devs/eth/mips/upd985xx/current/include/upd985xx_eth.h +++ b/packages/devs/eth/mips/upd985xx/current/include/upd985xx_eth.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/eth/mips/upd985xx/current/src/if_upd985xx.c b/packages/devs/eth/mips/upd985xx/current/src/if_upd985xx.c --- a/packages/devs/eth/mips/upd985xx/current/src/if_upd985xx.c +++ b/packages/devs/eth/mips/upd985xx/current/src/if_upd985xx.c @@ -35,7 +35,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/devs/eth/mips/vrc4375/current/ChangeLog b/packages/devs/eth/mips/vrc4375/current/ChangeLog --- a/packages/devs/eth/mips/vrc4375/current/ChangeLog +++ b/packages/devs/eth/mips/vrc4375/current/ChangeLog @@ -35,7 +35,7 @@ 2001-09-27 Hugo Tyson // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/mips/vrc4375/current/cdl/vrc4375_eth_drivers.cdl b/packages/devs/eth/mips/vrc4375/current/cdl/vrc4375_eth_drivers.cdl --- a/packages/devs/eth/mips/vrc4375/current/cdl/vrc4375_eth_drivers.cdl +++ b/packages/devs/eth/mips/vrc4375/current/cdl/vrc4375_eth_drivers.cdl @@ -7,36 +7,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/mips/vrc4375/current/include/devs_eth_vrc4375.inl b/packages/devs/eth/mips/vrc4375/current/include/devs_eth_vrc4375.inl --- a/packages/devs/eth/mips/vrc4375/current/include/devs_eth_vrc4375.inl +++ b/packages/devs/eth/mips/vrc4375/current/include/devs_eth_vrc4375.inl @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/eth/mn10300/asb2305/current/ChangeLog b/packages/devs/eth/mn10300/asb2305/current/ChangeLog --- a/packages/devs/eth/mn10300/asb2305/current/ChangeLog +++ b/packages/devs/eth/mn10300/asb2305/current/ChangeLog @@ -32,7 +32,7 @@ 2001-07-27 David Howells // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/eth/smsc/lan91cxx/current/cdl/smsc_lan91cxx_eth_drivers.cdl b/packages/devs/eth/smsc/lan91cxx/current/cdl/smsc_lan91cxx_eth_drivers.cdl --- a/packages/devs/eth/smsc/lan91cxx/current/cdl/smsc_lan91cxx_eth_drivers.cdl +++ b/packages/devs/eth/smsc/lan91cxx/current/cdl/smsc_lan91cxx_eth_drivers.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c b/packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c --- a/packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c +++ b/packages/devs/eth/smsc/lan91cxx/current/src/if_lan91cxx.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/devs/eth/smsc/lan91cxx/current/src/smsc_lan91cxx.h b/packages/devs/eth/smsc/lan91cxx/current/src/smsc_lan91cxx.h --- a/packages/devs/eth/smsc/lan91cxx/current/src/smsc_lan91cxx.h +++ b/packages/devs/eth/smsc/lan91cxx/current/src/smsc_lan91cxx.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/devs/eth/via/rhine/current/ChangeLog b/packages/devs/eth/via/rhine/current/ChangeLog --- a/packages/devs/eth/via/rhine/current/ChangeLog +++ b/packages/devs/eth/via/rhine/current/ChangeLog @@ -156,7 +156,7 @@ 2001-05-30 Jesper Skov // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/flash/arm/flexanet/current/cdl/flash_flexanet.cdl b/packages/devs/flash/arm/flexanet/current/cdl/flash_flexanet.cdl --- a/packages/devs/flash/arm/flexanet/current/cdl/flash_flexanet.cdl +++ b/packages/devs/flash/arm/flexanet/current/cdl/flash_flexanet.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/flash/arm/flexanet/current/include/flexanet_strataflash.inl b/packages/devs/flash/arm/flexanet/current/include/flexanet_strataflash.inl --- a/packages/devs/flash/arm/flexanet/current/include/flexanet_strataflash.inl +++ b/packages/devs/flash/arm/flexanet/current/include/flexanet_strataflash.inl @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/flash/arm/integrator/current/ChangeLog b/packages/devs/flash/arm/integrator/current/ChangeLog --- a/packages/devs/flash/arm/integrator/current/ChangeLog +++ b/packages/devs/flash/arm/integrator/current/ChangeLog @@ -49,7 +49,7 @@ 2001-10-30 Jonathan Larmour // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/devs/flash/arm/nano/current/cdl/flash_nano.cdl b/packages/devs/flash/arm/nano/current/cdl/flash_nano.cdl --- a/packages/devs/flash/arm/nano/current/cdl/flash_nano.cdl +++ b/packages/devs/flash/arm/nano/current/cdl/flash_nano.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/devs/flash/arm/nano/current/include/nano_strataflash.inl b/packages/devs/flash/arm/nano/current/include/nano_strataflash.inl --- a/packages/devs/flash/arm/nano/current/include/nano_strataflash.inl +++ b/packages/devs/flash/arm/nano/current/include/nano_strataflash.inl @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/devs/flash/arm/pid/current/ChangeLog b/packages/devs/flash/arm/pid/current/ChangeLog --- a/packages/devs/flash/arm/pid/current/ChangeLog +++ b/packages/devs/flash/arm/pid/current/ChangeLog @@ -37,7 +37,7 @@ 2001-02-20 Jesper Skov " diff --git a/packages/hal/arm/aeb/current/include/hal_cache.h b/packages/hal/arm/aeb/current/include/hal_cache.h --- a/packages/hal/arm/aeb/current/include/hal_cache.h +++ b/packages/hal/arm/aeb/current/include/hal_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/aeb/current/include/hal_diag.h b/packages/hal/arm/aeb/current/include/hal_diag.h --- a/packages/hal/arm/aeb/current/include/hal_diag.h +++ b/packages/hal/arm/aeb/current/include/hal_diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/aeb/current/include/hal_platform_ints.h b/packages/hal/arm/aeb/current/include/hal_platform_ints.h --- a/packages/hal/arm/aeb/current/include/hal_platform_ints.h +++ b/packages/hal/arm/aeb/current/include/hal_platform_ints.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/aeb/current/include/hal_platform_setup.h b/packages/hal/arm/aeb/current/include/hal_platform_setup.h --- a/packages/hal/arm/aeb/current/include/hal_platform_setup.h +++ b/packages/hal/arm/aeb/current/include/hal_platform_setup.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/aeb/current/include/plf_io.h b/packages/hal/arm/aeb/current/include/plf_io.h --- a/packages/hal/arm/aeb/current/include/plf_io.h +++ b/packages/hal/arm/aeb/current/include/plf_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/aeb/current/include/plf_stub.h b/packages/hal/arm/aeb/current/include/plf_stub.h --- a/packages/hal/arm/aeb/current/include/plf_stub.h +++ b/packages/hal/arm/aeb/current/include/plf_stub.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/aeb/current/src/Notes_GDB_stub b/packages/hal/arm/aeb/current/src/Notes_GDB_stub --- a/packages/hal/arm/aeb/current/src/Notes_GDB_stub +++ b/packages/hal/arm/aeb/current/src/Notes_GDB_stub @@ -1,35 +1,35 @@ =========================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### =========================================================================== diff --git a/packages/hal/arm/aeb/current/src/aeb_misc.c b/packages/hal/arm/aeb/current/src/aeb_misc.c --- a/packages/hal/arm/aeb/current/src/aeb_misc.c +++ b/packages/hal/arm/aeb/current/src/aeb_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/aeb/current/src/flash_cksum.tcl b/packages/hal/arm/aeb/current/src/flash_cksum.tcl --- a/packages/hal/arm/aeb/current/src/flash_cksum.tcl +++ b/packages/hal/arm/aeb/current/src/flash_cksum.tcl @@ -17,36 +17,36 @@ # #=============================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### #=============================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/arm/aeb/current/src/gdb_module.c b/packages/hal/arm/aeb/current/src/gdb_module.c --- a/packages/hal/arm/aeb/current/src/gdb_module.c +++ b/packages/hal/arm/aeb/current/src/gdb_module.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/aeb/current/src/hal_diag.c b/packages/hal/arm/aeb/current/src/hal_diag.c --- a/packages/hal/arm/aeb/current/src/hal_diag.c +++ b/packages/hal/arm/aeb/current/src/hal_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/arch/current/ChangeLog b/packages/hal/arm/arch/current/ChangeLog --- a/packages/hal/arm/arch/current/ChangeLog +++ b/packages/hal/arm/arch/current/ChangeLog @@ -1471,7 +1471,7 @@ 1998-10-16 Bart Veer + + * cdl/hal_arm_cma230.cdl: Don't run cache tests. + 2002-05-13 Jesper Skov * cdl/hal_arm_cma230.cdl: Removed implemntation of @@ -365,7 +369,7 @@ 1999-06-04 Gary Thomas " diff --git a/packages/hal/arm/cma230/current/include/hal_cache.h b/packages/hal/arm/cma230/current/include/hal_cache.h --- a/packages/hal/arm/cma230/current/include/hal_cache.h +++ b/packages/hal/arm/cma230/current/include/hal_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/hal_cma230.h b/packages/hal/arm/cma230/current/include/hal_cma230.h --- a/packages/hal/arm/cma230/current/include/hal_cma230.h +++ b/packages/hal/arm/cma230/current/include/hal_cma230.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/hal_diag.h b/packages/hal/arm/cma230/current/include/hal_diag.h --- a/packages/hal/arm/cma230/current/include/hal_diag.h +++ b/packages/hal/arm/cma230/current/include/hal_diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/hal_platform_extras.h b/packages/hal/arm/cma230/current/include/hal_platform_extras.h --- a/packages/hal/arm/cma230/current/include/hal_platform_extras.h +++ b/packages/hal/arm/cma230/current/include/hal_platform_extras.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/hal_platform_ints.h b/packages/hal/arm/cma230/current/include/hal_platform_ints.h --- a/packages/hal/arm/cma230/current/include/hal_platform_ints.h +++ b/packages/hal/arm/cma230/current/include/hal_platform_ints.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/cma230/current/include/hal_platform_setup.h b/packages/hal/arm/cma230/current/include/hal_platform_setup.h --- a/packages/hal/arm/cma230/current/include/hal_platform_setup.h +++ b/packages/hal/arm/cma230/current/include/hal_platform_setup.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/plf_io.h b/packages/hal/arm/cma230/current/include/plf_io.h --- a/packages/hal/arm/cma230/current/include/plf_io.h +++ b/packages/hal/arm/cma230/current/include/plf_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/include/plf_stub.h b/packages/hal/arm/cma230/current/include/plf_stub.h --- a/packages/hal/arm/cma230/current/include/plf_stub.h +++ b/packages/hal/arm/cma230/current/include/plf_stub.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/cma230/current/src/cma230_misc.c b/packages/hal/arm/cma230/current/src/cma230_misc.c --- a/packages/hal/arm/cma230/current/src/cma230_misc.c +++ b/packages/hal/arm/cma230/current/src/cma230_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/cma230/current/src/hal_diag.c b/packages/hal/arm/cma230/current/src/hal_diag.c --- a/packages/hal/arm/cma230/current/src/hal_diag.c +++ b/packages/hal/arm/cma230/current/src/hal_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/e7t/current/ChangeLog b/packages/hal/arm/e7t/current/ChangeLog --- a/packages/hal/arm/e7t/current/ChangeLog +++ b/packages/hal/arm/e7t/current/ChangeLog @@ -153,7 +153,7 @@ 2001-03-16 Jesper Skov + + * cdl/hal_arm_pid.cdl: Don't run cache tests. + 2002-05-13 Jesper Skov * cdl/hal_arm_pid.cdl: Removed implemntation of @@ -832,7 +836,7 @@ 1998-11-18 Gary Thomas " diff --git a/packages/hal/arm/pid/current/include/hal_cache.h b/packages/hal/arm/pid/current/include/hal_cache.h --- a/packages/hal/arm/pid/current/include/hal_cache.h +++ b/packages/hal/arm/pid/current/include/hal_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/include/hal_diag.h b/packages/hal/arm/pid/current/include/hal_diag.h --- a/packages/hal/arm/pid/current/include/hal_diag.h +++ b/packages/hal/arm/pid/current/include/hal_diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/include/hal_platform_ints.h b/packages/hal/arm/pid/current/include/hal_platform_ints.h --- a/packages/hal/arm/pid/current/include/hal_platform_ints.h +++ b/packages/hal/arm/pid/current/include/hal_platform_ints.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/pid/current/include/hal_platform_setup.h b/packages/hal/arm/pid/current/include/hal_platform_setup.h --- a/packages/hal/arm/pid/current/include/hal_platform_setup.h +++ b/packages/hal/arm/pid/current/include/hal_platform_setup.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/include/plf_io.h b/packages/hal/arm/pid/current/include/plf_io.h --- a/packages/hal/arm/pid/current/include/plf_io.h +++ b/packages/hal/arm/pid/current/include/plf_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/include/plf_stub.h b/packages/hal/arm/pid/current/include/plf_stub.h --- a/packages/hal/arm/pid/current/include/plf_stub.h +++ b/packages/hal/arm/pid/current/include/plf_stub.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/misc/dl.c b/packages/hal/arm/pid/current/misc/dl.c --- a/packages/hal/arm/pid/current/misc/dl.c +++ b/packages/hal/arm/pid/current/misc/dl.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/pid/current/src/Notes_GDB_stub b/packages/hal/arm/pid/current/src/Notes_GDB_stub --- a/packages/hal/arm/pid/current/src/Notes_GDB_stub +++ b/packages/hal/arm/pid/current/src/Notes_GDB_stub @@ -1,35 +1,35 @@ =========================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### =========================================================================== diff --git a/packages/hal/arm/pid/current/src/flash.c b/packages/hal/arm/pid/current/src/flash.c --- a/packages/hal/arm/pid/current/src/flash.c +++ b/packages/hal/arm/pid/current/src/flash.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/pid/current/src/hal_diag.c b/packages/hal/arm/pid/current/src/hal_diag.c --- a/packages/hal/arm/pid/current/src/hal_diag.c +++ b/packages/hal/arm/pid/current/src/hal_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/pid/current/src/pid_misc.c b/packages/hal/arm/pid/current/src/pid_misc.c --- a/packages/hal/arm/pid/current/src/pid_misc.c +++ b/packages/hal/arm/pid/current/src/pid_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/pid/current/src/prog_flash.c b/packages/hal/arm/pid/current/src/prog_flash.c --- a/packages/hal/arm/pid/current/src/prog_flash.c +++ b/packages/hal/arm/pid/current/src/prog_flash.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/sa11x0/assabet/current/ChangeLog b/packages/hal/arm/sa11x0/assabet/current/ChangeLog --- a/packages/hal/arm/sa11x0/assabet/current/ChangeLog +++ b/packages/hal/arm/sa11x0/assabet/current/ChangeLog @@ -336,7 +336,7 @@ 2000-05-10 Gary Thomas // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/arm/sa11x0/flexanet/current/cdl/hal_arm_sa11x0_flexanet.cdl b/packages/hal/arm/sa11x0/flexanet/current/cdl/hal_arm_sa11x0_flexanet.cdl --- a/packages/hal/arm/sa11x0/flexanet/current/cdl/hal_arm_sa11x0_flexanet.cdl +++ b/packages/hal/arm/sa11x0/flexanet/current/cdl/hal_arm_sa11x0_flexanet.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/arm/sa11x0/flexanet/current/include/flexanet.h b/packages/hal/arm/sa11x0/flexanet/current/include/flexanet.h --- a/packages/hal/arm/sa11x0/flexanet/current/include/flexanet.h +++ b/packages/hal/arm/sa11x0/flexanet/current/include/flexanet.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/flexanet/current/include/hal_platform_setup.h b/packages/hal/arm/sa11x0/flexanet/current/include/hal_platform_setup.h --- a/packages/hal/arm/sa11x0/flexanet/current/include/hal_platform_setup.h +++ b/packages/hal/arm/sa11x0/flexanet/current/include/hal_platform_setup.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/flexanet/current/include/plf_io.h b/packages/hal/arm/sa11x0/flexanet/current/include/plf_io.h --- a/packages/hal/arm/sa11x0/flexanet/current/include/plf_io.h +++ b/packages/hal/arm/sa11x0/flexanet/current/include/plf_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/flexanet/current/include/plf_mmap.h b/packages/hal/arm/sa11x0/flexanet/current/include/plf_mmap.h --- a/packages/hal/arm/sa11x0/flexanet/current/include/plf_mmap.h +++ b/packages/hal/arm/sa11x0/flexanet/current/include/plf_mmap.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/flexanet/current/src/flexanet_misc.c b/packages/hal/arm/sa11x0/flexanet/current/src/flexanet_misc.c --- a/packages/hal/arm/sa11x0/flexanet/current/src/flexanet_misc.c +++ b/packages/hal/arm/sa11x0/flexanet/current/src/flexanet_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/sa11x0/ipaq/current/ChangeLog b/packages/hal/arm/sa11x0/ipaq/current/ChangeLog --- a/packages/hal/arm/sa11x0/ipaq/current/ChangeLog +++ b/packages/hal/arm/sa11x0/ipaq/current/ChangeLog @@ -367,7 +367,7 @@ 2001-02-24 Gary Thomas // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/arm/sa11x0/nano/current/cdl/hal_arm_sa11x0_nano.cdl b/packages/hal/arm/sa11x0/nano/current/cdl/hal_arm_sa11x0_nano.cdl --- a/packages/hal/arm/sa11x0/nano/current/cdl/hal_arm_sa11x0_nano.cdl +++ b/packages/hal/arm/sa11x0/nano/current/cdl/hal_arm_sa11x0_nano.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/arm/sa11x0/nano/current/include/hal_platform_setup.h b/packages/hal/arm/sa11x0/nano/current/include/hal_platform_setup.h --- a/packages/hal/arm/sa11x0/nano/current/include/hal_platform_setup.h +++ b/packages/hal/arm/sa11x0/nano/current/include/hal_platform_setup.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/nano/current/include/nano.h b/packages/hal/arm/sa11x0/nano/current/include/nano.h --- a/packages/hal/arm/sa11x0/nano/current/include/nano.h +++ b/packages/hal/arm/sa11x0/nano/current/include/nano.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/nano/current/include/plf_io.h b/packages/hal/arm/sa11x0/nano/current/include/plf_io.h --- a/packages/hal/arm/sa11x0/nano/current/include/plf_io.h +++ b/packages/hal/arm/sa11x0/nano/current/include/plf_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/nano/current/include/plf_mmap.h b/packages/hal/arm/sa11x0/nano/current/include/plf_mmap.h --- a/packages/hal/arm/sa11x0/nano/current/include/plf_mmap.h +++ b/packages/hal/arm/sa11x0/nano/current/include/plf_mmap.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/arm/sa11x0/nano/current/src/nano_misc.c b/packages/hal/arm/sa11x0/nano/current/src/nano_misc.c --- a/packages/hal/arm/sa11x0/nano/current/src/nano_misc.c +++ b/packages/hal/arm/sa11x0/nano/current/src/nano_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/arm/sa11x0/sa1100mm/current/ChangeLog b/packages/hal/arm/sa11x0/sa1100mm/current/ChangeLog --- a/packages/hal/arm/sa11x0/sa1100mm/current/ChangeLog +++ b/packages/hal/arm/sa11x0/sa1100mm/current/ChangeLog @@ -122,7 +122,7 @@ 2000-10-25 Drew Moseley + + * cdl/hal.cdl: Don't build tests that are not applicable with the + current configuration. + Added CYGINT_HAL_TESTS_NO_CACHES which allows cache tests to be + suppressed. + 2002-05-13 Jesper Skov * cdl/hal.cdl: Removed @@ -2104,7 +2111,7 @@ 1998-08-18 Nick Garnett + + * include/var_arch.h: Added __ASSEMBLER__ protection. + 2002-02-11 Jesper Skov * include/variant.inc: Initialize TRAP vector with break_vsr to @@ -102,7 +106,7 @@ 2000-07-14 Drew Moseley + + * include/var_arch.h: Added __ASSEMBLER__ protection. + 2001-12-04 Nick Garnett * include/var_arch.h: Added macros to read/write CP0 registers. @@ -60,7 +64,7 @@ 2001-01-30 Nick Garnett // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/mips/upd985xx/current/cdl/hal_mips_upd985xx.cdl b/packages/hal/mips/upd985xx/current/cdl/hal_mips_upd985xx.cdl --- a/packages/hal/mips/upd985xx/current/cdl/hal_mips_upd985xx.cdl +++ b/packages/hal/mips/upd985xx/current/cdl/hal_mips_upd985xx.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mips/upd985xx/current/include/hal_diag.h b/packages/hal/mips/upd985xx/current/include/hal_diag.h --- a/packages/hal/mips/upd985xx/current/include/hal_diag.h +++ b/packages/hal/mips/upd985xx/current/include/hal_diag.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/mips/upd985xx/current/include/plf_stub.h b/packages/hal/mips/upd985xx/current/include/plf_stub.h --- a/packages/hal/mips/upd985xx/current/include/plf_stub.h +++ b/packages/hal/mips/upd985xx/current/include/plf_stub.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/mips/upd985xx/current/include/var_arch.h b/packages/hal/mips/upd985xx/current/include/var_arch.h --- a/packages/hal/mips/upd985xx/current/include/var_arch.h +++ b/packages/hal/mips/upd985xx/current/include/var_arch.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mips/upd985xx/current/include/var_cache.h b/packages/hal/mips/upd985xx/current/include/var_cache.h --- a/packages/hal/mips/upd985xx/current/include/var_cache.h +++ b/packages/hal/mips/upd985xx/current/include/var_cache.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/mips/upd985xx/current/include/var_intr.h b/packages/hal/mips/upd985xx/current/include/var_intr.h --- a/packages/hal/mips/upd985xx/current/include/var_intr.h +++ b/packages/hal/mips/upd985xx/current/include/var_intr.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mips/upd985xx/current/include/variant.inc b/packages/hal/mips/upd985xx/current/include/variant.inc --- a/packages/hal/mips/upd985xx/current/include/variant.inc +++ b/packages/hal/mips/upd985xx/current/include/variant.inc @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //#============================================================================= diff --git a/packages/hal/mips/upd985xx/current/src/hal_diag.c b/packages/hal/mips/upd985xx/current/src/hal_diag.c --- a/packages/hal/mips/upd985xx/current/src/hal_diag.c +++ b/packages/hal/mips/upd985xx/current/src/hal_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/mips/upd985xx/current/src/hal_mips_upd985xx.ld b/packages/hal/mips/upd985xx/current/src/hal_mips_upd985xx.ld --- a/packages/hal/mips/upd985xx/current/src/hal_mips_upd985xx.ld +++ b/packages/hal/mips/upd985xx/current/src/hal_mips_upd985xx.ld @@ -32,7 +32,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/mips/upd985xx/current/src/var_misc.c b/packages/hal/mips/upd985xx/current/src/var_misc.c --- a/packages/hal/mips/upd985xx/current/src/var_misc.c +++ b/packages/hal/mips/upd985xx/current/src/var_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mips/upd985xx/current/src/variant.S b/packages/hal/mips/upd985xx/current/src/variant.S --- a/packages/hal/mips/upd985xx/current/src/variant.S +++ b/packages/hal/mips/upd985xx/current/src/variant.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mips/vr4300/current/ChangeLog b/packages/hal/mips/vr4300/current/ChangeLog --- a/packages/hal/mips/vr4300/current/ChangeLog +++ b/packages/hal/mips/vr4300/current/ChangeLog @@ -295,7 +295,7 @@ 1999-04-21 Nick Garnett + + * include/var_cache.h (HAL_DCACHE_STORE): Fix warning. + 2001-10-15 Nick Garnett * src/mn10300_am31.ld: Added test for __GNUC__ >= 3 so that diff --git a/packages/hal/mn10300/am31/current/cdl/hal_mn10300_am31.cdl b/packages/hal/mn10300/am31/current/cdl/hal_mn10300_am31.cdl --- a/packages/hal/mn10300/am31/current/cdl/hal_mn10300_am31.cdl +++ b/packages/hal/mn10300/am31/current/cdl/hal_mn10300_am31.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mn10300/am31/current/include/var_arch.h b/packages/hal/mn10300/am31/current/include/var_arch.h --- a/packages/hal/mn10300/am31/current/include/var_arch.h +++ b/packages/hal/mn10300/am31/current/include/var_arch.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am31/current/include/var_cache.h b/packages/hal/mn10300/am31/current/include/var_cache.h --- a/packages/hal/mn10300/am31/current/include/var_cache.h +++ b/packages/hal/mn10300/am31/current/include/var_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= @@ -200,7 +200,7 @@ externC void cyg_hal_dcache_store(CYG_ADDRWORD base, int size); #define HAL_DCACHE_STORE( _base_ , _size_ ) \ - cyg_hal_dcache_store((_base_), (_size_)) + cyg_hal_dcache_store((CYG_ADDRWORD)(_base_), (int)(_size_)) // Preread the given range into the cache with the intention of reading // from it later. diff --git a/packages/hal/mn10300/am31/current/include/var_intr.h b/packages/hal/mn10300/am31/current/include/var_intr.h --- a/packages/hal/mn10300/am31/current/include/var_intr.h +++ b/packages/hal/mn10300/am31/current/include/var_intr.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am31/current/include/variant.inc b/packages/hal/mn10300/am31/current/include/variant.inc --- a/packages/hal/mn10300/am31/current/include/variant.inc +++ b/packages/hal/mn10300/am31/current/include/variant.inc @@ -8,36 +8,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mn10300/am31/current/src/mn10300_am31.ld b/packages/hal/mn10300/am31/current/src/mn10300_am31.ld --- a/packages/hal/mn10300/am31/current/src/mn10300_am31.ld +++ b/packages/hal/mn10300/am31/current/src/mn10300_am31.ld @@ -33,7 +33,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/mn10300/am31/current/src/var_misc.c b/packages/hal/mn10300/am31/current/src/var_misc.c --- a/packages/hal/mn10300/am31/current/src/var_misc.c +++ b/packages/hal/mn10300/am31/current/src/var_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am33/current/cdl/hal_mn10300_am33.cdl b/packages/hal/mn10300/am33/current/cdl/hal_mn10300_am33.cdl --- a/packages/hal/mn10300/am33/current/cdl/hal_mn10300_am33.cdl +++ b/packages/hal/mn10300/am33/current/cdl/hal_mn10300_am33.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mn10300/am33/current/include/var_arch.h b/packages/hal/mn10300/am33/current/include/var_arch.h --- a/packages/hal/mn10300/am33/current/include/var_arch.h +++ b/packages/hal/mn10300/am33/current/include/var_arch.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am33/current/include/var_cache.h b/packages/hal/mn10300/am33/current/include/var_cache.h --- a/packages/hal/mn10300/am33/current/include/var_cache.h +++ b/packages/hal/mn10300/am33/current/include/var_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/mn10300/am33/current/include/var_intr.h b/packages/hal/mn10300/am33/current/include/var_intr.h --- a/packages/hal/mn10300/am33/current/include/var_intr.h +++ b/packages/hal/mn10300/am33/current/include/var_intr.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am33/current/include/variant.inc b/packages/hal/mn10300/am33/current/include/variant.inc --- a/packages/hal/mn10300/am33/current/include/variant.inc +++ b/packages/hal/mn10300/am33/current/include/variant.inc @@ -8,36 +8,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mn10300/am33/current/src/mn10300_am33.ld b/packages/hal/mn10300/am33/current/src/mn10300_am33.ld --- a/packages/hal/mn10300/am33/current/src/mn10300_am33.ld +++ b/packages/hal/mn10300/am33/current/src/mn10300_am33.ld @@ -33,7 +33,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/mn10300/am33/current/src/var_misc.c b/packages/hal/mn10300/am33/current/src/var_misc.c --- a/packages/hal/mn10300/am33/current/src/var_misc.c +++ b/packages/hal/mn10300/am33/current/src/var_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/mn10300/am33/current/src/variant.S b/packages/hal/mn10300/am33/current/src/variant.S --- a/packages/hal/mn10300/am33/current/src/variant.S +++ b/packages/hal/mn10300/am33/current/src/variant.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/mn10300/arch/current/ChangeLog b/packages/hal/mn10300/arch/current/ChangeLog --- a/packages/hal/mn10300/arch/current/ChangeLog +++ b/packages/hal/mn10300/arch/current/ChangeLog @@ -897,7 +897,7 @@ 1998-08-17 Nick Garnett + + * misc/gdb_module.ecm: New file - ecosconfig data used to + build ROM based GDB stubs. + 2002-05-13 Jesper Skov * cdl/hal_powerpc_cogent.cdl: Removed implemntation of @@ -743,7 +748,7 @@ Mon Aug 17 22:13:41 1998 Jonathan Larmo // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/powerpc/cogent/current/cdl/hal_powerpc_cogent.cdl b/packages/hal/powerpc/cogent/current/cdl/hal_powerpc_cogent.cdl --- a/packages/hal/powerpc/cogent/current/cdl/hal_powerpc_cogent.cdl +++ b/packages/hal/powerpc/cogent/current/cdl/hal_powerpc_cogent.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/powerpc/cogent/current/include/hal_diag.h b/packages/hal/powerpc/cogent/current/include/hal_diag.h --- a/packages/hal/powerpc/cogent/current/include/hal_diag.h +++ b/packages/hal/powerpc/cogent/current/include/hal_diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/cogent/current/include/plf_cache.h b/packages/hal/powerpc/cogent/current/include/plf_cache.h --- a/packages/hal/powerpc/cogent/current/include/plf_cache.h +++ b/packages/hal/powerpc/cogent/current/include/plf_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/cogent/current/include/plf_intr.h b/packages/hal/powerpc/cogent/current/include/plf_intr.h --- a/packages/hal/powerpc/cogent/current/include/plf_intr.h +++ b/packages/hal/powerpc/cogent/current/include/plf_intr.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/powerpc/cogent/current/include/plf_stub.h b/packages/hal/powerpc/cogent/current/include/plf_stub.h --- a/packages/hal/powerpc/cogent/current/include/plf_stub.h +++ b/packages/hal/powerpc/cogent/current/include/plf_stub.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/cogent/current/misc/gdb_module.ecm b/packages/hal/powerpc/cogent/current/misc/gdb_module.ecm new file mode 100644 --- /dev/null +++ b/packages/hal/powerpc/cogent/current/misc/gdb_module.ecm @@ -0,0 +1,58 @@ +cdl_savefile_version 1; +cdl_savefile_command cdl_savefile_version {}; +cdl_savefile_command cdl_savefile_command {}; +cdl_savefile_command cdl_configuration { description hardware template package }; +cdl_savefile_command cdl_package { value_source user_value wizard_value inferred_value }; +cdl_savefile_command cdl_component { value_source user_value wizard_value inferred_value }; +cdl_savefile_command cdl_option { value_source user_value wizard_value inferred_value }; +cdl_savefile_command cdl_interface { value_source user_value wizard_value inferred_value }; + +cdl_configuration eCos { + description "" ; + hardware cma28x ; + template stubs ; + package -hardware CYGPKG_HAL_POWERPC current ; + package -hardware CYGPKG_HAL_POWERPC_MPC8xx current ; + package -hardware CYGPKG_HAL_POWERPC_COGENT current ; + package -hardware CYGPKG_IO_SERIAL_POWERPC_COGENT current ; + package -template CYGPKG_HAL current ; + package -template CYGPKG_INFRA current ; + package -template CYGPKG_ISOINFRA current ; + package -template CYGPKG_IO current ; + package -template CYGPKG_IO_SERIAL current ; + package -template CYGPKG_ERROR current ; +}; + +cdl_option CYGBLD_BUILD_COMMON_GDB_STUBS { + user_value 1 +}; + +cdl_option CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS { + inferred_value 1 +}; + +cdl_option CYGSEM_HAL_ROM_MONITOR { + user_value 1 +}; + +cdl_component CYG_HAL_STARTUP { + user_value ROM +}; + +cdl_option CYGBLD_ISO_ERRNO_CODES_HEADER { + inferred_value 1 +}; + +cdl_option CYGBLD_ISO_ERRNO_HEADER { + inferred_value 1 +}; + +cdl_option CYGBLD_ISO_STRERROR_HEADER { + inferred_value 1 +}; + +cdl_option CYGSEM_ERROR_PER_THREAD_ERRNO { + inferred_value 0 +}; + + diff --git a/packages/hal/powerpc/cogent/current/src/cogent.S b/packages/hal/powerpc/cogent/current/src/cogent.S --- a/packages/hal/powerpc/cogent/current/src/cogent.S +++ b/packages/hal/powerpc/cogent/current/src/cogent.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/powerpc/cogent/current/src/hal_diag.c b/packages/hal/powerpc/cogent/current/src/hal_diag.c --- a/packages/hal/powerpc/cogent/current/src/hal_diag.c +++ b/packages/hal/powerpc/cogent/current/src/hal_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/cogent/current/src/plf_misc.c b/packages/hal/powerpc/cogent/current/src/plf_misc.c --- a/packages/hal/powerpc/cogent/current/src/plf_misc.c +++ b/packages/hal/powerpc/cogent/current/src/plf_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/cogent/current/src/plf_stub.c b/packages/hal/powerpc/cogent/current/src/plf_stub.c --- a/packages/hal/powerpc/cogent/current/src/plf_stub.c +++ b/packages/hal/powerpc/cogent/current/src/plf_stub.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/powerpc/ec555/current/ChangeLog b/packages/hal/powerpc/ec555/current/ChangeLog --- a/packages/hal/powerpc/ec555/current/ChangeLog +++ b/packages/hal/powerpc/ec555/current/ChangeLog @@ -37,7 +37,7 @@ 2002-04-24 Bob Koninckx + + * src/var_intr.c: Fixed warning. + * src/var_misc.c: Same. + 2002-05-13 Gary Thomas * cdl/hal_powerpc_ppc40x.cdl: This processor family has no FPU. @@ -86,7 +91,7 @@ 2000-11-04 Gary Thomas #include +extern void hal_platform_IRQ_init(void); + + static cyg_uint32 exier_mask[] = { 0x00000000, // Unused 0x00000000, // Unused diff --git a/packages/hal/powerpc/ppc40x/current/src/var_misc.c b/packages/hal/powerpc/ppc40x/current/src/var_misc.c --- a/packages/hal/powerpc/ppc40x/current/src/var_misc.c +++ b/packages/hal/powerpc/ppc40x/current/src/var_misc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -59,6 +59,8 @@ #include +void hal_ppc40x_clock_initialize(cyg_uint32 period); + //-------------------------------------------------------------------------- void hal_variant_init(void) { @@ -145,7 +147,7 @@ cyg_hal_clear_MMU (void) static cyg_uint32 _period; extern cyg_uint32 _hold_tcr; // Shadow of TCR register which can't be read -externC void +void hal_ppc40x_clock_initialize(cyg_uint32 period) { cyg_uint32 tcr; diff --git a/packages/hal/powerpc/ppc40x/current/src/variant.S b/packages/hal/powerpc/ppc40x/current/src/variant.S --- a/packages/hal/powerpc/ppc40x/current/src/variant.S +++ b/packages/hal/powerpc/ppc40x/current/src/variant.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/powerpc/ppc60x/current/ChangeLog b/packages/hal/powerpc/ppc60x/current/ChangeLog --- a/packages/hal/powerpc/ppc60x/current/ChangeLog +++ b/packages/hal/powerpc/ppc60x/current/ChangeLog @@ -79,7 +79,7 @@ 2000-02-07 Jesper Skov + + * cdl/hal_sh_sh2.cdl: Select variant 7044 by default. + 2002-05-08 Jesper Skov * src/sh2_sci.c: Register renaming. @@ -364,7 +368,7 @@ 2002-01-09 Jesper Skov + + * cdl/hal_sh_sh3.cdl: Select variant 7709A by default. + 2002-05-08 Jesper Skov * src/sh3_sci.c: Register renaming. @@ -213,7 +217,7 @@ 2000-08-15 Haruki Kashiwaya + + * cdl/hal_sh_sh4.cdl: Select variant 7750 by default. + 2002-05-08 Jesper Skov * src/sh4_scif.c: Register renaming. @@ -253,7 +257,7 @@ 2000-04-18 Ryozaburo Suzuki + + * cdl/hal_synth.cdl: Don't run cache tests. + 2002-04-10 Jonathan Larmour * src/synth.ld: Add RELOCS "section" and eh_frame section, plus @@ -384,7 +388,7 @@ Mon Nov 9 15:18:11 GMT 1998 Chris Pro // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/synth/arch/current/cdl/hal_synth.cdl b/packages/hal/synth/arch/current/cdl/hal_synth.cdl --- a/packages/hal/synth/arch/current/cdl/hal_synth.cdl +++ b/packages/hal/synth/arch/current/cdl/hal_synth.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### @@ -61,6 +61,8 @@ cdl_package CYGPKG_HAL_SYNTH { support needed to run eCos binaries on top of a Linux kernel." + implements CYGINT_HAL_TESTS_NO_CACHES + make { /lib/target.ld: /src/synth.ld $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH) $(CFLAGS) -o $@ $< diff --git a/packages/hal/synth/arch/current/doc/makefile b/packages/hal/synth/arch/current/doc/makefile --- a/packages/hal/synth/arch/current/doc/makefile +++ b/packages/hal/synth/arch/current/doc/makefile @@ -6,36 +6,36 @@ # #============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### #============================================================================= #####DESCRIPTIONBEGIN#### diff --git a/packages/hal/synth/arch/current/doc/synth.sgml b/packages/hal/synth/arch/current/doc/synth.sgml --- a/packages/hal/synth/arch/current/doc/synth.sgml +++ b/packages/hal/synth/arch/current/doc/synth.sgml @@ -9,38 +9,38 @@ -####ECOSGPLCOPYRIGHTBEGIN#### - ------------------------------------------- - This file is part of eCos, the Embedded Configurable Operating System. - Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. - - eCos is free software; you can redistribute it and/or modify it under - the terms of the GNU General Public License as published by the Free - Software Foundation; either version 2 or (at your option) any later version. - - eCos is distributed in the hope that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty of MERCHANTABILITY or - FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - for more details. - - You should have received a copy of the GNU General Public License along - with eCos; if not, write to the Free Software Foundation, Inc., - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. - - As a special exception, if other files instantiate templates or use macros - or inline functions from this file, or you compile this file and link it - with other works to produce a work based on this file, this file does not - by itself cause the resulting work to be covered by the GNU General Public - License. However the source code for this file must still be made available - in accordance with section (3) of the GNU General Public License. - - This exception does not invalidate any other reasons why a work based on - this file might be covered by the GNU General Public License. - - Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. - at http://sources.redhat.com/ecos/ecos-license - ------------------------------------------- -####ECOSGPLCOPYRIGHTEND#### +#####ECOSGPLCOPYRIGHTBEGIN#### +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- +#####ECOSGPLCOPYRIGHTEND#### diff --git a/packages/hal/synth/arch/current/include/hal_arch.h b/packages/hal/synth/arch/current/include/hal_arch.h --- a/packages/hal/synth/arch/current/include/hal_arch.h +++ b/packages/hal/synth/arch/current/include/hal_arch.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/arch/current/include/hal_cache.h b/packages/hal/synth/arch/current/include/hal_cache.h --- a/packages/hal/synth/arch/current/include/hal_cache.h +++ b/packages/hal/synth/arch/current/include/hal_cache.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/arch/current/include/hal_diag.h b/packages/hal/synth/arch/current/include/hal_diag.h --- a/packages/hal/synth/arch/current/include/hal_diag.h +++ b/packages/hal/synth/arch/current/include/hal_diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/arch/current/include/hal_intr.h b/packages/hal/synth/arch/current/include/hal_intr.h --- a/packages/hal/synth/arch/current/include/hal_intr.h +++ b/packages/hal/synth/arch/current/include/hal_intr.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/synth/arch/current/include/hal_io.h b/packages/hal/synth/arch/current/include/hal_io.h --- a/packages/hal/synth/arch/current/include/hal_io.h +++ b/packages/hal/synth/arch/current/include/hal_io.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/arch/current/src/synth.ld b/packages/hal/synth/arch/current/src/synth.ld --- a/packages/hal/synth/arch/current/src/synth.ld +++ b/packages/hal/synth/arch/current/src/synth.ld @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/synth/arch/current/src/synth_diag.c b/packages/hal/synth/arch/current/src/synth_diag.c --- a/packages/hal/synth/arch/current/src/synth_diag.c +++ b/packages/hal/synth/arch/current/src/synth_diag.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/arch/current/src/synth_entry.c b/packages/hal/synth/arch/current/src/synth_entry.c --- a/packages/hal/synth/arch/current/src/synth_entry.c +++ b/packages/hal/synth/arch/current/src/synth_entry.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/hal/synth/arch/current/src/synth_intr.c b/packages/hal/synth/arch/current/src/synth_intr.c --- a/packages/hal/synth/arch/current/src/synth_intr.c +++ b/packages/hal/synth/arch/current/src/synth_intr.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/i386linux/current/ChangeLog b/packages/hal/synth/i386linux/current/ChangeLog --- a/packages/hal/synth/i386linux/current/ChangeLog +++ b/packages/hal/synth/i386linux/current/ChangeLog @@ -378,7 +378,7 @@ Mon Nov 9 15:18:11 GMT 1998 Chris Pro // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl b/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl --- a/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl +++ b/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/hal/synth/i386linux/current/include/arch.inc b/packages/hal/synth/i386linux/current/include/arch.inc --- a/packages/hal/synth/i386linux/current/include/arch.inc +++ b/packages/hal/synth/i386linux/current/include/arch.inc @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/synth/i386linux/current/include/basetype.h b/packages/hal/synth/i386linux/current/include/basetype.h --- a/packages/hal/synth/i386linux/current/include/basetype.h +++ b/packages/hal/synth/i386linux/current/include/basetype.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/i386linux/current/include/var_arch.h b/packages/hal/synth/i386linux/current/include/var_arch.h --- a/packages/hal/synth/i386linux/current/include/var_arch.h +++ b/packages/hal/synth/i386linux/current/include/var_arch.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/i386linux/current/src/context.S b/packages/hal/synth/i386linux/current/src/context.S --- a/packages/hal/synth/i386linux/current/src/context.S +++ b/packages/hal/synth/i386linux/current/src/context.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S b/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S --- a/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S +++ b/packages/hal/synth/i386linux/current/src/syscall-i386-linux-1.0.S @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/hal/synth/i386linux/current/src/vectors.S b/packages/hal/synth/i386linux/current/src/vectors.S --- a/packages/hal/synth/i386linux/current/src/vectors.S +++ b/packages/hal/synth/i386linux/current/src/vectors.S @@ -6,36 +6,36 @@ ## ##============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### ##============================================================================= #######DESCRIPTIONBEGIN#### diff --git a/packages/hal/v85x/arch/current/ChangeLog b/packages/hal/v85x/arch/current/ChangeLog --- a/packages/hal/v85x/arch/current/ChangeLog +++ b/packages/hal/v85x/arch/current/ChangeLog @@ -247,7 +247,7 @@ 2000-03-21 Gary Thomas + + * cdl/hal_v85x_v850.cdl: Don't run cache tests. + 2001-06-21 Jonathan Larmour * include/v850_common.h: Add register defns for other V850/SA1 models. @@ -153,7 +157,7 @@ 2000-03-20 Gary Thomas + + * src/diag.cxx (_vprintf): Mapping of '\n'=>'\r\n' must be done + at the _putc() level. + 2002-04-17 Gary Thomas * src/diag.cxx (diag_dump_buf_with_offset): Fix pad for short lines. @@ -855,7 +860,7 @@ 1998-08-20 Nick Garnett 0) { c = *cp++; - if (c == '\n') { - (*putc)('\r', param); - res++; - } (*putc)(c, param); res++; } @@ -493,10 +489,6 @@ static int } } } else { - if (c == '\n') { - (*putc)('\r', param); - res++; - } (*putc)(c, param); res++; } diff --git a/packages/infra/current/src/dummyxxmain.cxx b/packages/infra/current/src/dummyxxmain.cxx --- a/packages/infra/current/src/dummyxxmain.cxx +++ b/packages/infra/current/src/dummyxxmain.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/infra/current/src/eprintf.c b/packages/infra/current/src/eprintf.c --- a/packages/infra/current/src/eprintf.c +++ b/packages/infra/current/src/eprintf.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/infra/current/src/fancy.cxx b/packages/infra/current/src/fancy.cxx --- a/packages/infra/current/src/fancy.cxx +++ b/packages/infra/current/src/fancy.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/memcpy.c b/packages/infra/current/src/memcpy.c --- a/packages/infra/current/src/memcpy.c +++ b/packages/infra/current/src/memcpy.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/memset.c b/packages/infra/current/src/memset.c --- a/packages/infra/current/src/memset.c +++ b/packages/infra/current/src/memset.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/null.cxx b/packages/infra/current/src/null.cxx --- a/packages/infra/current/src/null.cxx +++ b/packages/infra/current/src/null.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/pkgstart.cxx b/packages/infra/current/src/pkgstart.cxx --- a/packages/infra/current/src/pkgstart.cxx +++ b/packages/infra/current/src/pkgstart.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/infra/current/src/prestart.cxx b/packages/infra/current/src/prestart.cxx --- a/packages/infra/current/src/prestart.cxx +++ b/packages/infra/current/src/prestart.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/infra/current/src/simple.cxx b/packages/infra/current/src/simple.cxx --- a/packages/infra/current/src/simple.cxx +++ b/packages/infra/current/src/simple.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/startup.cxx b/packages/infra/current/src/startup.cxx --- a/packages/infra/current/src/startup.cxx +++ b/packages/infra/current/src/startup.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/infra/current/src/tcdiag.cxx b/packages/infra/current/src/tcdiag.cxx --- a/packages/infra/current/src/tcdiag.cxx +++ b/packages/infra/current/src/tcdiag.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/infra/current/src/userstart.cxx b/packages/infra/current/src/userstart.cxx --- a/packages/infra/current/src/userstart.cxx +++ b/packages/infra/current/src/userstart.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/io/common/current/ChangeLog b/packages/io/common/current/ChangeLog --- a/packages/io/common/current/ChangeLog +++ b/packages/io/common/current/ChangeLog @@ -223,7 +223,7 @@ 1999-02-25 Gary Thomas + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __LWIPOPTS_H__ +#define __LWIPOPTS_H__ @@ -391,7 +391,7 @@ diff -Nur lwip-0.5.3/proj/ecos/simhost.c + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ + +#include "lwip/debug.h" @@ -587,7 +587,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __ARCH_CC_H__ +#define __ARCH_CC_H__ @@ -642,7 +642,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __ARCH_CPU_H__ +#define __ARCH_CPU_H__ @@ -690,7 +690,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __ARCH_INIT_H__ +#define __ARCH_INIT_H__ @@ -738,7 +738,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __ARCH_LIB_H__ +#define __ARCH_LIB_H__ @@ -780,7 +780,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __PERF_H__ +#define __PERF_H__ @@ -842,7 +842,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/inclu + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ +#ifndef __ECOSIF_H__ +#define __ECOSIF_H__ @@ -888,7 +888,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/lib_a + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ + +/* These are generic implementations of various library functions used @@ -984,7 +984,7 @@ diff -Nur lwip-0.5.3/src/arch/ecos/netif + * + * Author: Adam Dunkels + * -+ * $Id: lw.diff,v 1.1 2002/05/20 22:24:22 jlarmour Exp $ ++ * $Id: lw.diff,v 1.2 2002/05/23 23:06:02 jlarmour Exp $ + */ + +#include "lwip/debug.h" diff --git a/packages/io/eth/current/src/net/eth_drv.c b/packages/io/eth/current/src/net/eth_drv.c --- a/packages/io/eth/current/src/net/eth_drv.c +++ b/packages/io/eth/current/src/net/eth_drv.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/eth/current/src/stand_alone/eth_drv.c b/packages/io/eth/current/src/stand_alone/eth_drv.c --- a/packages/io/eth/current/src/stand_alone/eth_drv.c +++ b/packages/io/eth/current/src/stand_alone/eth_drv.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/cdl/fileio.cdl b/packages/io/fileio/current/cdl/fileio.cdl --- a/packages/io/fileio/current/cdl/fileio.cdl +++ b/packages/io/fileio/current/cdl/fileio.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/io/fileio/current/include/dirent.h b/packages/io/fileio/current/include/dirent.h --- a/packages/io/fileio/current/include/dirent.h +++ b/packages/io/fileio/current/include/dirent.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/io/fileio/current/include/fileio.h b/packages/io/fileio/current/include/fileio.h --- a/packages/io/fileio/current/include/fileio.h +++ b/packages/io/fileio/current/include/fileio.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/io/fileio/current/include/inode.h b/packages/io/fileio/current/include/inode.h --- a/packages/io/fileio/current/include/inode.h +++ b/packages/io/fileio/current/include/inode.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/io/fileio/current/include/limits.h b/packages/io/fileio/current/include/limits.h --- a/packages/io/fileio/current/include/limits.h +++ b/packages/io/fileio/current/include/limits.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================ diff --git a/packages/io/fileio/current/include/sockio.h b/packages/io/fileio/current/include/sockio.h --- a/packages/io/fileio/current/include/sockio.h +++ b/packages/io/fileio/current/include/sockio.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/io/fileio/current/src/devfs.cxx b/packages/io/fileio/current/src/devfs.cxx --- a/packages/io/fileio/current/src/devfs.cxx +++ b/packages/io/fileio/current/src/devfs.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/dir.cxx b/packages/io/fileio/current/src/dir.cxx --- a/packages/io/fileio/current/src/dir.cxx +++ b/packages/io/fileio/current/src/dir.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/fd.cxx b/packages/io/fileio/current/src/fd.cxx --- a/packages/io/fileio/current/src/fd.cxx +++ b/packages/io/fileio/current/src/fd.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/file.cxx b/packages/io/fileio/current/src/file.cxx --- a/packages/io/fileio/current/src/file.cxx +++ b/packages/io/fileio/current/src/file.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/fio.h b/packages/io/fileio/current/src/fio.h --- a/packages/io/fileio/current/src/fio.h +++ b/packages/io/fileio/current/src/fio.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/io/fileio/current/src/inocache.cxx b/packages/io/fileio/current/src/inocache.cxx --- a/packages/io/fileio/current/src/inocache.cxx +++ b/packages/io/fileio/current/src/inocache.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/io/fileio/current/src/io.cxx b/packages/io/fileio/current/src/io.cxx --- a/packages/io/fileio/current/src/io.cxx +++ b/packages/io/fileio/current/src/io.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/misc.cxx b/packages/io/fileio/current/src/misc.cxx --- a/packages/io/fileio/current/src/misc.cxx +++ b/packages/io/fileio/current/src/misc.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/select.cxx b/packages/io/fileio/current/src/select.cxx --- a/packages/io/fileio/current/src/select.cxx +++ b/packages/io/fileio/current/src/select.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/src/socket.cxx b/packages/io/fileio/current/src/socket.cxx --- a/packages/io/fileio/current/src/socket.cxx +++ b/packages/io/fileio/current/src/socket.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/tests/fileio1.c b/packages/io/fileio/current/tests/fileio1.c --- a/packages/io/fileio/current/tests/fileio1.c +++ b/packages/io/fileio/current/tests/fileio1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/tests/select.c b/packages/io/fileio/current/tests/select.c --- a/packages/io/fileio/current/tests/select.c +++ b/packages/io/fileio/current/tests/select.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/tests/socket.c b/packages/io/fileio/current/tests/socket.c --- a/packages/io/fileio/current/tests/socket.c +++ b/packages/io/fileio/current/tests/socket.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/tests/stdio.c b/packages/io/fileio/current/tests/stdio.c --- a/packages/io/fileio/current/tests/stdio.c +++ b/packages/io/fileio/current/tests/stdio.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/fileio/current/tests/testfs.c b/packages/io/fileio/current/tests/testfs.c --- a/packages/io/fileio/current/tests/testfs.c +++ b/packages/io/fileio/current/tests/testfs.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/flash/current/ChangeLog b/packages/io/flash/current/ChangeLog --- a/packages/io/flash/current/ChangeLog +++ b/packages/io/flash/current/ChangeLog @@ -254,7 +254,7 @@ 2000-07-29 Gary Thomas -####ECOSGPLCOPYRIGHTBEGIN#### - ------------------------------------------- - This file is part of eCos, the Embedded Configurable Operating System. - Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. - - eCos is free software; you can redistribute it and/or modify it under - the terms of the GNU General Public License as published by the Free - Software Foundation; either version 2 or (at your option) any later version. - - eCos is distributed in the hope that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty of MERCHANTABILITY or - FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - for more details. - - You should have received a copy of the GNU General Public License along - with eCos; if not, write to the Free Software Foundation, Inc., - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. - - As a special exception, if other files instantiate templates or use macros - or inline functions from this file, or you compile this file and link it - with other works to produce a work based on this file, this file does not - by itself cause the resulting work to be covered by the GNU General Public - License. However the source code for this file must still be made available - in accordance with section (3) of the GNU General Public License. - - This exception does not invalidate any other reasons why a work based on - this file might be covered by the GNU General Public License. - - Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. - at http://sources.redhat.com/ecos/ecos-license - ------------------------------------------- -####ECOSGPLCOPYRIGHTEND#### +#####ECOSGPLCOPYRIGHTBEGIN#### +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- +#####ECOSGPLCOPYRIGHTEND#### diff --git a/packages/io/usb/eth/slave/current/host/ecos_usbeth.c b/packages/io/usb/eth/slave/current/host/ecos_usbeth.c --- a/packages/io/usb/eth/slave/current/host/ecos_usbeth.c +++ b/packages/io/usb/eth/slave/current/host/ecos_usbeth.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/usb/eth/slave/current/include/usbs_eth.h b/packages/io/usb/eth/slave/current/include/usbs_eth.h --- a/packages/io/usb/eth/slave/current/include/usbs_eth.h +++ b/packages/io/usb/eth/slave/current/include/usbs_eth.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/usb/eth/slave/current/src/usbseth.c b/packages/io/usb/eth/slave/current/src/usbseth.c --- a/packages/io/usb/eth/slave/current/src/usbseth.c +++ b/packages/io/usb/eth/slave/current/src/usbseth.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/usb/eth/slave/current/src/usbsethdrv.c b/packages/io/usb/eth/slave/current/src/usbsethdrv.c --- a/packages/io/usb/eth/slave/current/src/usbsethdrv.c +++ b/packages/io/usb/eth/slave/current/src/usbsethdrv.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/usb/slave/current/ChangeLog b/packages/io/usb/slave/current/ChangeLog --- a/packages/io/usb/slave/current/ChangeLog +++ b/packages/io/usb/slave/current/ChangeLog @@ -119,7 +119,7 @@ 2000-11-21 Bart Veer -####ECOSGPLCOPYRIGHTBEGIN#### - ------------------------------------------- - This file is part of eCos, the Embedded Configurable Operating System. - Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. - - eCos is free software; you can redistribute it and/or modify it under - the terms of the GNU General Public License as published by the Free - Software Foundation; either version 2 or (at your option) any later version. - - eCos is distributed in the hope that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty of MERCHANTABILITY or - FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - for more details. - - You should have received a copy of the GNU General Public License along - with eCos; if not, write to the Free Software Foundation, Inc., - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. - - As a special exception, if other files instantiate templates or use macros - or inline functions from this file, or you compile this file and link it - with other works to produce a work based on this file, this file does not - by itself cause the resulting work to be covered by the GNU General Public - License. However the source code for this file must still be made available - in accordance with section (3) of the GNU General Public License. - - This exception does not invalidate any other reasons why a work based on - this file might be covered by the GNU General Public License. - - Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. - at http://sources.redhat.com/ecos/ecos-license - ------------------------------------------- -####ECOSGPLCOPYRIGHTEND#### +#####ECOSGPLCOPYRIGHTBEGIN#### +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- +#####ECOSGPLCOPYRIGHTEND#### diff --git a/packages/io/usb/slave/current/include/usbs.h b/packages/io/usb/slave/current/include/usbs.h --- a/packages/io/usb/slave/current/include/usbs.h +++ b/packages/io/usb/slave/current/include/usbs.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/usb/slave/current/src/usbs.c b/packages/io/usb/slave/current/src/usbs.c --- a/packages/io/usb/slave/current/src/usbs.c +++ b/packages/io/usb/slave/current/src/usbs.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/ChangeLog b/packages/io/wallclock/current/ChangeLog --- a/packages/io/wallclock/current/ChangeLog +++ b/packages/io/wallclock/current/ChangeLog @@ -298,7 +298,7 @@ Wed Jul 22 21:04:15 1998 Jonathan Larmo // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### diff --git a/packages/io/wallclock/current/cdl/wallclock.cdl b/packages/io/wallclock/current/cdl/wallclock.cdl --- a/packages/io/wallclock/current/cdl/wallclock.cdl +++ b/packages/io/wallclock/current/cdl/wallclock.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/io/wallclock/current/include/wallclock.hxx b/packages/io/wallclock/current/include/wallclock.hxx --- a/packages/io/wallclock/current/include/wallclock.hxx +++ b/packages/io/wallclock/current/include/wallclock.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/include/wallclock/wallclock.inl b/packages/io/wallclock/current/include/wallclock/wallclock.inl --- a/packages/io/wallclock/current/include/wallclock/wallclock.inl +++ b/packages/io/wallclock/current/include/wallclock/wallclock.inl @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/src/emulate.cxx b/packages/io/wallclock/current/src/emulate.cxx --- a/packages/io/wallclock/current/src/emulate.cxx +++ b/packages/io/wallclock/current/src/emulate.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/src/wallclock.cxx b/packages/io/wallclock/current/src/wallclock.cxx --- a/packages/io/wallclock/current/src/wallclock.cxx +++ b/packages/io/wallclock/current/src/wallclock.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/tests/wallclock.cxx b/packages/io/wallclock/current/tests/wallclock.cxx --- a/packages/io/wallclock/current/tests/wallclock.cxx +++ b/packages/io/wallclock/current/tests/wallclock.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/wallclock/current/tests/wallclock2.cxx b/packages/io/wallclock/current/tests/wallclock2.cxx --- a/packages/io/wallclock/current/tests/wallclock2.cxx +++ b/packages/io/wallclock/current/tests/wallclock2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/io/watchdog/current/ChangeLog b/packages/io/watchdog/current/ChangeLog --- a/packages/io/watchdog/current/ChangeLog +++ b/packages/io/watchdog/current/ChangeLog @@ -288,6 +288,6 @@ 1998-07-29 Nick Garnett + + * include/kapi.h: Expose new cyg_thread_add_destructor and + cyg_thread_rem_destructor APIs. + + * include/kapidata.h (struct Cyg_Destructor_Entry): + Change CYG_ADDRWORD to more correct cyg_addrword_t. + + * include/thread.hxx (class Cyg_Thread): add_destructor and + rem_destructor are onyl static when not per-thread. + + * include/thread.inl (add_destructor): Don't need to lock and unlock + scheduler when destructors are per-thread. + (rem_destructor): Ditto. + + * src/common/thread.cxx (exit): No need to lock scheduler when + calling destructors. + + * doc/kernel.sgml: Document thread destructor API. + +2002-05-23 Nick Garnett + + * doc/kernel.sgml: Some more edits to the kernel documentation: + changed all references to message boxes to mail boxes, clarified + some thing in various places, fixed a few typos. + +2002-05-23 Jesper Skov + + * cdl/kernel.cdl: Cleaned up kernel tests rule. Also remove tests + depending on the C API when its not present. And skip dhrystone + test when debug or instrumentation is enabled. + + * tests/tm_basic.cxx: Fixed warning. + +2002-05-22 Nick Garnett + + * doc/kernel.sgml: + Fixed up SMP documentation. + Rewrote condtion variable documentation to make its relationship + to mutexes more apparent. + +2002-05-22 Jesper Skov + + * tests/smp.cxx: Move inclusion of testaux.hxx to below NA + checks. + +2002-05-21 Bart Veer + + * doc/kernel.sgml: + Major update to the kernel documentation. + +2002-05-21 Jesper Skov + + * src/common/clock.cxx (dsr): Fix latency ifdef guards. + * tests/tm_basic.cxx: Same. + +2002-05-20 Jonathan Larmour + + * src/sched/mlqueue.cxx: Don't force timeslice tracing on by default + against the user's wishes. + * cdl/scheduler.cdl: Instead provide an option controlling it. + 2002-05-09 Jonathan Larmour * include/kapidata.h (CYG_HARDWARETHREAD_MEMBERS): entry_point @@ -4172,7 +4234,7 @@ Wed Mar 11 13:18:17 GMT 1998 Chris Prov // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //=========================================================================== diff --git a/packages/kernel/current/cdl/counters.cdl b/packages/kernel/current/cdl/counters.cdl --- a/packages/kernel/current/cdl/counters.cdl +++ b/packages/kernel/current/cdl/counters.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/kernel/current/cdl/instrument.cdl b/packages/kernel/current/cdl/instrument.cdl --- a/packages/kernel/current/cdl/instrument.cdl +++ b/packages/kernel/current/cdl/instrument.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/kernel/current/cdl/interrupts.cdl b/packages/kernel/current/cdl/interrupts.cdl --- a/packages/kernel/current/cdl/interrupts.cdl +++ b/packages/kernel/current/cdl/interrupts.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/kernel/current/cdl/kernel.cdl b/packages/kernel/current/cdl/kernel.cdl --- a/packages/kernel/current/cdl/kernel.cdl +++ b/packages/kernel/current/cdl/kernel.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### @@ -327,14 +327,11 @@ cdl_package CYGPKG_KERNEL { flavor data no_define calculated { - CYGPKG_HAL_ARM_AEB ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/timeslice" : \ - CYGPKG_HAL_ARM_EBSA285 ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/stress_threads tests/kcache1 tests/kcache2 tests/timeslice" : \ - CYGPKG_HAL_ARM_SA11X0 ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/clocktruth tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/stress_threads tests/kcache1 tests/kcache2 tests/timeslice" : \ - CYGPKG_HAL_ARM_EDB7XXX ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/stress_threads tests/kcache1 tests/kcache2 tests/timeslice" : \ - CYGPKG_HAL_ARM_CMA230 ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/cnt_sem0 tests/cnt_sem1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/timeslice" : \ - CYGPKG_HAL_ARM_E7T ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/stress_threads tests/kcache1 tests/kcache2 tests/timeslice" : \ - CYGPKG_HAL_ARM ? "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/clocktruth tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/timeslice" : \ - "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/clocktruth tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kclock0 tests/kclock1 tests/kexcept1 tests/kintr0 tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kflag0 tests/kflag1 tests/klock tests/kthread0 tests/kthread1 tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2 tests/release tests/kill tests/thread_gdb tests/tm_basic tests/dhrystone tests/stress_threads tests/kcache1 tests/kcache2 tests/smp tests/timeslice" + "tests/bin_sem0 tests/bin_sem1 tests/bin_sem2 tests/clock0 tests/clock1 tests/clockcnv tests/clocktruth tests/cnt_sem0 tests/cnt_sem1 tests/except1 tests/flag0 tests/flag1 tests/intr0 tests/kill tests/mbox1 tests/mqueue1 tests/mutex0 tests/mutex1 tests/mutex2 tests/mutex3 tests/release tests/sched1 tests/sync2 tests/sync3 tests/thread0 tests/thread1 tests/thread2" + . ((CYGFUN_KERNEL_API_C) ? "tests/kclock0 tests/kclock1 tests/kexcept1 tests/kflag0 tests/kflag1 tests/kintr0 tests/klock tests/kmbox1 tests/kmutex0 tests/kmutex1 tests/kmutex3 tests/kmutex4 tests/ksched1 tests/ksem0 tests/ksem1 tests/kthread0 tests/kthread1 tests/stress_threads tests/thread_gdb tests/timeslice tests/tm_basic" : "") + . ((!CYGPKG_INFRA_DEBUG && !CYGPKG_KERNEL_INSTRUMENT && CYGFUN_KERNEL_API_C) ? " tests/dhrystone" : "") + . ((CYGPKG_KERNEL_SMP_SUPPORT && CYGFUN_KERNEL_API_C) ? " tests/smp" : "") + . ((!CYGINT_HAL_TESTS_NO_CACHES && CYGFUN_KERNEL_API_C) ? " tests/kcache1 tests/kcache2" : "") } description " This option specifies the set of tests for the eCos kernel." diff --git a/packages/kernel/current/cdl/scheduler.cdl b/packages/kernel/current/cdl/scheduler.cdl --- a/packages/kernel/current/cdl/scheduler.cdl +++ b/packages/kernel/current/cdl/scheduler.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### @@ -64,7 +64,7 @@ cdl_interface CYGINT_KERNEL_SCHEDULER_UN } # FIXME: The two below options must be mutually exclusive -cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE { +cdl_component CYGSEM_KERNEL_SCHED_MLQUEUE { display "Multi-level queue scheduler" default_value 1 implements CYGINT_KERNEL_SCHEDULER @@ -74,6 +74,18 @@ cdl_option CYGSEM_KERNEL_SCHED_MLQUEUE { Preemption between priority levels is automatic. Timeslicing within a given priority level is controlled by a separate configuration option." + + cdl_option CYGDBG_KERNEL_TRACE_TIMESLICE { + display "Output timeslices when tracing" + active_if CYGDBG_USE_TRACING + requires !CYGDBG_INFRA_DEBUG_TRACE_ASSERT_SIMPLE + requires !CYGDBG_INFRA_DEBUG_TRACE_ASSERT_FANCY + default_value 0 + description " + When tracing is enabled, output trace messages every + timeslice. This can be quite verbose so is disabled by + default." + } } cdl_option CYGSEM_KERNEL_SCHED_BITMAP { diff --git a/packages/kernel/current/cdl/synch.cdl b/packages/kernel/current/cdl/synch.cdl --- a/packages/kernel/current/cdl/synch.cdl +++ b/packages/kernel/current/cdl/synch.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/kernel/current/cdl/thread.cdl b/packages/kernel/current/cdl/thread.cdl --- a/packages/kernel/current/cdl/thread.cdl +++ b/packages/kernel/current/cdl/thread.cdl @@ -6,36 +6,36 @@ # # ==================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### # ==================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/kernel/current/doc/kernel.sgml b/packages/kernel/current/doc/kernel.sgml --- a/packages/kernel/current/doc/kernel.sgml +++ b/packages/kernel/current/doc/kernel.sgml @@ -1,3716 +1,5310 @@ - - The eCos kernel - -eCos kernel overview -This is an overview of the internal workings of the - eCos - kernel. - -<!-- <xref> -->The scheduler -At the core of the kernel is the scheduler. -This defines the way in which threads are run, and provides the mechanisms -by which they may synchronize. It also controls the means by which interrupts -affect thread execution. No single scheduler can cover all possible system -configurations. For different purposes we will need to cover several scheduling -polices. In this release two schedulers are provided (described -in more detail in ): - - -a bitmap scheduler - - -a multi-level queue scheduler - - - -At present the system will only support a single scheduler -at any one time. Future systems may allow multiple schedulers to -co-exist, but this will be hidden behind the scheduler API in the -current release. -To make scheduling safe we need a mechanism to protect the -scheduler data structures from concurrent access. The traditional -approach to this is to disable interrupts during the critical regions. -Unfortunately this increases the maximum interrupt dispatch latency, -which is to be avoided in any real-time system. -The mechanisms chosen for eCos is to -maintain a counter, Scheduler::sched_lock -that, if non-zero, prevents any rescheduling. The current thread -can claim the lock by calling Scheduler::lock(). -This increments the counter and prevents any further scheduling. -The function Scheduler::unlock() -decrements the counter and if it returns to zero, allows scheduling -to continue. -For this to work in the presence of interrupts, it is necessary -for the Interrupt Service Routines (ISR) to defer -any scheduler-oriented operations until the lock is about to go -zero. We do this by splitting the work of an ISR into two parts, -with the second part, the Deferred Service Routine -(DSR), being queued until the scheduler decides it is safe to run. -This is covered in more detail in and - . -On a uni-processor, - Scheduler::lock() is a simple increment - of Scheduler::sched_lock. It does - not need to be a read-modify-write cycle since the lock is - strictly nested. The mere fact that the current thread is - running implies that the lock has not been claimed by - another thread, so it is always claimable. -Scheduler::unlock() is generic to - all scheduler implementations. - - -Thread <!-- <index></index> --> -synchronization -To allow threads to cooperate and compete for resources, - it is necessary to provide mechanisms for synchronization - and communication. The classic synchronization mechanisms - are mutexes/condition variables and semaphores. These - are provided in the eCos kernel, - together with other synchronization/communication - mechanisms that are common in real-time systems, such as - event flags and message queues. -One of the problems that must be dealt with in any real-time -systems is priority inversion. This is where a high -priority thread is (wrongly) prevented from continuing by one at -lower priority. The normal example is of a high priority thread -waiting at a mutex already held by a low priority thread. If the -low priority thread is preempted by a medium priority thread then -priority inversion has occurred since the high priority thread is -prevented from continuing by an unrelated thread of lower priority. -This problem got much attention recently when the Mars Pathfinder -mission had to reset the computers on the ground exploration robot -repeatedly because a priority inversion problem would cause it to -hang. -There are several solutions to this problem. The simplest -is to employ a priority ceiling protocol where all -threads that acquire the mutex have their priority boosted to some -predetermined value. This has a number of disadvantages: it requires -the maximum priority of the threads using the mutex to be known -in advance; if the ceiling priority is too high it acts as a global -lock disabling all scheduling and it is pessimistic, taking action -to prevent the problem even when it does not arise. -A better solution is to use priority inheritance -protocol. Here, the priority of the thread that owns the mutex is boosted -to equal that of the highest priority thread that is waiting for -it. This technique does not require prior knowledge of the priorities -of the threads that are going to use the mutex, and the priority -of the owning thread is only boosted when a higher priority thread -is waiting. This reduces the effect on the scheduling of other threads, -and is more optimistic than the priority ceiling protocol. A disadvantage -of this mechanism is that the cost of each synchronization call -is increased since the inheritance protocol must be obeyed each -time. -A third approach to priority inversion is to recognize that -relative thread priorities have been poorly chosen and thus the -system in which it occurs is faulty. In this case the kernel needs -the ability to detect when priority inversion has taken place, and -to raise an exception when it occurs to aid debugging. Then this -code is removed from the shipping version. -The current eCos release provides a relatively -simple implementation of mutex priority inheritance. -This implementation will only work in the multi-level queue scheduler, -and it does not handle the rare case of nested mutexes completely correctly. -However it is both fast and deterministic. Mutex priority inheritance -can be disabled if the application does not require it. This will -reduce both code size and data space. -Future releases will provide alternative implementations of -mutex priority inheritance, and application developers will be able -to choose the implementation appropriate to their application. - - -Exceptions -An exception is a synchronous event caused by the execution -of a thread. These include both the machine exceptions raised by -hardware (such as divide-by-zero, memory fault and illegal instruction) -and machine exceptions raised by software (such as deadline overrun). -The standard C++ exception mechanism is too expensive -to use for this, and in any case has the wrong semantics for the exception -handling in an RTOS. -The simplest, and most flexible, mechanism for exception -handling is to call a function. This function needs context in which -to work, so access to some working data is required. The function -may also need to be handed some data about the exception raised: -at least the exception number and some optional parameters. -The exception handler receives a data argument which is a -value that was registered with the handler and points to context -information. It also receives an exception_number which -identifies the exception taken, and an error code which contains -any additional information (such as a memory fault address) needed -to handle the exception. Returning from the function will allow -the thread to continue. -Exception handlers may be either global or per-thread, or -both, depending on configuration options. If exceptions are per-thread, -it is necessary to have an exception handler attached to each thread. - - -<!-- <xref> -->Interrupts -Interrupts are asynchronous events caused by external devices. -They may occur at any time and are not associated in any way with -the thread that is currently running. -The handling of interrupts is one of the more -complex areas in RTOS design, largely because it is the least well -defined. The ways in which interrupt vectors are named, how interrupts -are delivered to the software and how interrupts are masked are -all highly architecture- (and in some cases board-) specific. The -approach taken in eCos is to provide a generalized mechanism -with sufficient hooks for system-specific code to be inserted where -needed. -Let us start by considering the issue of interrupt vectors. -Hardware support differs greatly here: from the Intel Architecture -and the 680X0 having support for vectoring individual interrupts -to their own vectors, to most RISC architectures that only have -a single vector. In the first case it is possible to attach an ISR directly -to the vector and know that it need only concern itself with the -device in question. In the second case it is necessary to determine -which device is actually interrupting and then vector to the correct -ISR. Where there is an external interrupt controller, it will be -possible to query that and provide what is essentially a software -implementation of hardware vectoring. Otherwise the actual hardware devices -must be tested, by calling the ISRs in turn and letting them make -the determination. Since it is possible for two devices to interrupt -simultaneously, it is necessary to call all ISRs each time an interrupt -occurs. -Interrupt masking has a similar variety of support. Most processors -have a simple interrupt mask bit in a status register. The 680X0 -has seven levels of masking. Any board with a interrupt controller -can be programmed to provide similar multi-level masking. It is -necessary to keep the interrupt masking mechanism simple and efficient, -and use only architectural support. The cost of manipulating an -on-board interrupt controller may be too high. However, individual -device drivers may want access to their individual mask bits in -the interrupt controller, so support for this must be provided. -Most of the infrastructure necessary for a (somewhat) portable -treatment of interrupts is implemented in the eCos Hardware -Abstraction Layer (HAL), which is documented in . - - -Counters, clocks, alarms and timers -If the hardware provides a periodic clock or timer, it will -be used to drive timing-related features of the system. Many CPU -architectures now have built in timer registers that can provide -a periodic interrupt. This should be used to drive these features -where possible. Otherwise an external timer/clock chip -must be used. -We draw a distinction between Counters, Clocks, Alarms and -Timers. A Counter maintains a monotonically increasing -counter that is driven by some source of ticks. A Clock -is a counter driven by a regular source of ticks (i.e. it counts -time). Clocks have a resolution associated with them. -A default system Clock is driven by the periodic interrupt described -above, and tracks real-time. Other interrupt sources may drive other -Counters that may or may not track real-time at different resolutions. -Some Counters may be driven by aperiodic events and thus have no relation -to real-time at all. -An Alarm is attached to a Counter and provides -a mechanism for generating single-shot or periodic events based -on the counter's value. A Timer is simply -an Alarm that is attached to a Clock. -The system (including the kernel) represents time in units -of ticks. These are clock-specific time units -and are usually the period of the timer interrupt, or a multiple -thereof. Conversion of ticks into conventional time and date units -should occur only when required via library functions. Equivalence -between Clock time and real-time can be made with an RTC -(real-time clock), NTP (network time protocol) or -user input. -The representation of the current tick count needs to be 64 -bit. This requires either compiler support for 64 bit integers, -or assembly code. Even at the extreme of a 1 ns tick (ticks will -typically be >1ms), this gives a 584 year rollover period. -The Clock API and configuration options that affect clock, -counter and alarm behavior are described in detail in . - - - -A tour of the kernel sources -This description takes the form of a tour around the - sources explaining their structure and describing the - functionality of each component. -The kernel is divided into two basic parts, the largely machine -independent parts in packages/kernel/&versiondir;, -and the architecture- and platform-specific parts that comprise -the Hardware Abstraction Layer (HAL) in packages/hal. -These will be described separately. Also note that the HAL is described -in great detail in its own chapter (). - -<!-- <index></index> -->Kernel headers -Kernel header files (in packages/kernel/&versiondir;/include) -provide external interfaces and configuration control for the various -kernel objects. In general there is an include file for each major -kernel class. Those header files having to do with configuration -live in the pkgconf subdirectory. -The base name of a header file and the source file that implements -it are usually the same. So, for example, the member functions defined -in sched.hxx are implemented in sched.cxx. -For a number of classes there are also header files that define -inline functions, for example sched.inl. -There are some kernel objects that are implemented using C++ templates -to allow code re-use in future; it is not intended that these template -classes be used generally by applications. The appropriate concrete -kernel classes should be used instead. -Now we examine the files one by one for reference: - - -include/bitmap.hxx - -Bitmap scheduler definition. See source file - sched/bitmap.cxx - - - -include/clock.hxx -include/clock.inl - - -Counter, clock and alarm functions. See source - file - common/clock.cxx - - - -include/diag.h - - - -Diagnostic routines. See source file - trace/diag.c - - - -include/errors.h - - - -Kernel error codes. See source file - common/except.cxx - - - -include/except.hxx - - - -Exception handling. - - - -include/flag.hxx - - - -Flag synchronization objects. See source file - sync/flag.cxx - - - -include/instrmnt.h - - - -Instrumentation. See source file - instrmnt/meminst.cxx - - - -include/intr.hxx - - - -Interrupts. See source file - intr/intr.cxx - - - -include/kapi.h -include/kapidata.h - - -Native 'C' API to the kernel. See source -file - common/kapi.cxx - - - -include/ktypes.h - - - -Kernel types. - - - -include/llistt.hxx - - - -A simple doubly linked-list template class used elsewhere -in the kernel. - - - -include/lottery.hxx - - - -Lottery scheduler implementation. (Not used). See source file - sched/lottery.cxx - - - -include/mbox.hxx -include/mboxt.hxx -include/mboxt2.hxx -include/mboxt.inl -include/mboxt2.inl - - - -Message boxes. See source file sync/mbox.cxx; mboxt.hxx and mboxt2.hxx and mboxt.inl and mboxt2.inl implement -the underlying template function. - -The files with a 2 suffix are used by default and - provide precise µITRON semantics. - - - - -include/memfixed.hxx -include/mempoolt.hxx -include/mempolt2.hxx -include/mempoolt.inl -include/mempolt2.inl -include/mfiximpl.hxx -include/mfiximpl.inl - - - -Fixed-block allocation memory pools. See source file mem/memfixed.cxx; -mempoolt[2] and mfiximpl are a thread-safety template -function and underlying memory manager respectively. - -The files with a 2 suffix are used by default and provide - precise µITRON semantics. - - - - -include/memvar.hxx -include/mempoolt.hxx -include/mempolt2.hxx -include/mempoolt.inl -include/mempolt2.inl -include/mvarimpl.hxx -include/mvarimpl.inl - - -Variable-block allocation memory pools. See source file mem/memvar.cxx; -mempoolt[2] and mvar are a thread-safety template -function and underlying memory manager respectively. - -The files with a 2 suffix are used by default and provide - precise µITRON semantics. - - - - -include/mlqueue.hxx - - - -Multi-level queue scheduler. See source file - sched/mlqueue.cxx - - - -include/mutex.hxx - - - -Mutexes. See source file - sync/mutex.cxx - - - -include/sched.hxx -include/sched.inl - - -General scheduler functions. See source file - sched/sched.cxx - - - -include/sema.hxx -include/sema2.hxx - - -Semaphores. See source files sync/cnt_sem.cxx and sync/bin_sem.cxx for - counting or binary semaphores respectively. - -The file with a 2 suffix is used by default - and provides precise µITRON - semantics. - - - - -include/thread.hxx -include/thread.inl - - -Threads, regardless of scheduler. See - common/thread.cxx - - - - - -<!-- <index></index> --> Kernel source files -The kernel source directory (packages/kernel/&versiondir;/src) -is divided into a number of sub-directories each containing the -source files for a particular kernel subsystem. These sources divide -into two classes: those that are generic to all configurations, -and those that are specific to a particular configuration. - -<!-- <index></index> --><!-- <xref> -->Sched subdirectory - - -sched/sched.cxx - - - -This contains the implementation of the base - scheduler classes. The most important function here - is - Cyg_Scheduler::unlock_inner() - which runs DSRs and performs any rescheduling and - thread switching. - - - -sched/bitmap.cxx - - - -This contains the bitmap scheduler implementation. It represents -each runnable thread with a bit in a bitmap. Each thread must have -a unique priority and there is a strict upper limit on the number -of threads allowed. - - - -sched/mlqueue.cxx - - - -This contains the multi-level queue scheduler implementation. -It implements a number of thread priorities and is capable of timeslicing -between threads at the same priority. This scheduler can also support -priority inheritance. - - - -sched/lottery.cxx - - - -This contains a lottery scheduler implementation. This implements -a CPU share scheduler based on threads holding a number of lottery -tickets. At the start of each time quantum, a random number is generated -and the thread holding the matching ticket is scheduled. Compensation -tickets and ticket donation allow fair sharing for I/O -bound threads and an equivalent mechanism to priority - inheritance. - -This scheduler is experimental, and is meant to - test the behavior of other parts of the kernel with a - non-orthodox scheduler. It is not meant to be used for - real applications. It is currently under development and - is incomplete and unusable. - - - - - - -<!-- <index></index> --> Common subdirectory - - -common/thread.cxx - - - -This implements the basic thread classes. The - functions in this file implement the basic thread - controls to sleep and wake threads, change - priorities and delay and time-out. Also defined here - is the idle thread that runs when there is nothing - else to do. - - - -common/clock.cxx - - - -This implements the counter, clock and alarm functions. Also -defined here is the system real-time clock that is used to drive -timeslicing, delays and time-outs. - - - -common/kapi.cxx - - - -This implements a C API to the basic kernel - functions. - - - -common/memcpy.c -common/memset.c - - -Standard ANSI memcpy and memset operations; these are here -because the compiler may invoke them for structure operations regardless -of the presence of a C library. - - - - - -<!-- <index></index> --> Interrupt subdirectory - - -intr/intr.cxx - - - -This implements the Interrupt class. Most of this code is -concerned with posting and calling DSRs. The remainder of the interrupt -handling code is machine specific and is in hal_intr.cxx in -the HAL directory. - - - - - -<!-- <index></index> -->Synchronization subdirectory - - -sync/mutex.cxx - - - -This contains the implementation of mutexes and condition -variables. Mutexes can optionally be configured to use a priority -inheritance mechanism supplied by the scheduler. - - - -sync/cnt_sem.cxx - - - -This contains the implementation of counting - semaphores. - - - -sync/cnt_sem2.cxx - - - -This contains the alternate implementation of counting semaphores -which implements precise µITRON - semantics. - - - -sync/bin_sem.cxx - - - -This contains the implementation of binary - semaphores. - - - -sync/mbox.cxx - - - -This contains wrapper functions for a message box of (void *) -values. The implementation is the template defined in include/mboxt.hxx which include/mboxt.inl implements -in turn. Message boxes exist in the kernel specifically to support µITRON -compatibility. - - - -sync/flag.cxx - - - -This contains the implementation of flag objects. Flag objects -exist in the kernel specifically to support µITRON -compatibility. - - - - - -<!-- <index></index> -->Memory management subdirectory - - -mem/memfixed.cxx - - - -This contains the wrapper functions for a fixed-block allocation -memory manager. The actual implementation is in two parts: include/mfiximpl.hxx implements -the fixed-block memory management algorithms, and template include/mempoolt.hxx implements -thread safety and waiting for memory management classes. These are combined -in memfixed.cxx. Memory pools exist -in the kernel specifically to support µITRON -compatibility. - - - -mem/memvar.cxx - - - -This contains the wrapper functions for a variable-block allocation -memory manager. The actual implementation is in two parts: include/mvarimpl.hxx implements -the variable-block memory management algorithms, and template include/mempoolt.hxx implements -thread safety and waiting for memory management classes. These are combined -in memvar.cxx. Memory pools exist -in the kernel specifically to support µITRON -compatibility. - - - - - -<!-- <index></index> -->Instrumentation subdirectory - - -instrmnt/meminst.cxx - - - -This contains an implementation of the instrumentation mechanism -that stores instrumentation records in a circular buffer in memory. -The size of this buffer is configurable. The instrumentation flags -mechanism allows the generation of instrumentation records to be -controlled on a per-record basis. The header file cyg/kernel/instrmnt.h contains -macros to generate instrumentation records in various places, and -may be configured to only generate instrumentation records where -required. - - - -instrmnt/nullinst.cxx - - - -This contains an implementation of the instrumentation mechanism -that does nothing. By substituting its object file nullinst.o for meminst.o in -a build, the instrumentation mechanism may be disabled without - recompiling. - - - - - -<!-- <index></index> -->Trace subdirectory - - -trace/simple.cxx - - - -This contains an implementation of the trace and assert mechanisms -that output textual messages via a set of externally defined functions. -These are currently supplied by the code in trace/diag.c but -may be supplied by a device driver in the future. - - - -trace/fancy.cxx - - - -This contains a (fancier) implementation of the trace and -assert mechanisms that output textual messages via a set of externally -defined functions. These are currently supplied by the code in trace/diag.c but -may be supplied by a device driver in the future. -This more elaborate view was introduced mainly to validate -the trace and assertion macros during development. - - - -trace/null.cxx - - - -This contains an implementation of the trace and assert mechanisms -that do nothing. By substituting its object file null.o for simple.o in -a build, the trace mechanisms may be disabled without - recompiling. - - - -trace/diag.c - - - -This contains a number of diagnostic routines that use the -HAL supplied diagnostic output mechanism to format and print strings -and numbers. There is currently no formatted output. - - - -trace/tcdiag.c - - - -This contains an implementation of the testing internal API -which uses the kernel's diagnostic routines to perform -output. - - - - - -<!-- <index></index> -->Sload subdirectory -This contains the sources of a simple S-Record loader that -may be used in a ROM for various microprocessor development boards -to download code via a serial port. - - -<!-- <index></index> -->HAL source files -The HAL is divided into architecture- and platform-specific -files. For each architecture supported, there is an arch directory, -containing files generic to that architecture, and a platform directory, -containing files specific to each platform supported. -Amongst the architectures supported are: the PowerPC, the -Tx39 and the MN10300. To find the code corresponding to each architecture, -substitute “powerpc”, “mips” and “mn10300”, -respectively, for “ARCH” in the following file -descriptions. Similarly substitute the appropriate platform name -representing your development board for “PLATFORM”. - - -<!-- <index></index> -->Architecture files - - -ARCH/arch/&versiondir;/include/basetype.h - - -This file is used to define the base architecture configuration -such as endianness and word size. - - - -ARCH/arch/&versiondir;/include/hal_arch.h - - -This file contains macros that implement various architecture-specific -functions. The most important macros here are the thread context -initialization and switch macros that are used to implement - multithreading. - - - -ARCH/arch/&versiondir;/include/hal_intr.h - - - -This file contains the HAL support for interrupt management -and clock support. - - - -ARCH/arch/&versiondir;/include/hal_io.h - - - -This file contains the HAL support for accessing hardware -registers. It provides a portable API that allows more generic device -drivers to be written. - - - -ARCH/arch/&versiondir;/include/hal_cache.h - - - -This file contains macros to control any caches that may be -present. - - - -ARCH/arch/&versiondir;/include/ARCH_stub.h - - - -This file contains architectural information for a GDB stub, -such as the register layout in a GDB packet. - - - -ARCH/arch/&versiondir;/src/vectors.S - - - -This is an assembly code file that contains the code to handle -interrupt and exception vectors. Since system reset can also be -considered an exception, this is handled here also. Interrupts are -currently handled by placing a stub routine in the hardware vector -which calls a Vector Service Routine via an indirection table. There -is a API to allow user-defined VSRs to be installed. The default -VSR reads the interrupt controller registers and decodes the interrupt -source into an offset into a further table of interrupt service -routines. It also handles interrupt cleanup, which may result in -the execution of deferred service routines (DSRs) and the preemption of -the current thread. - - - -ARCH/arch/&versiondir;/src/context.S - - - -If present, this is an assembly code file that contains the -code to support thread contexts. The routines to switch between -various contexts, as well as initialize a thread context may be -present in this file. - - - -ARCH/arch/&versiondir;/src/hal_misc.c - - - -This file contains the implementation of various miscellaneous -HAL routines that are needed by the kernel or C++ - runtime. - - - -ARCH/arch/&versiondir;/src/ARCH_stub.c - - - -This file contains the architectural part of a GDB stub. This -deals with CPU-specific details of the stub, such as the setting -of breakpoints and translating exception data into signals that -GDB understands. - - - -ARCH/arch/&versiondir;/src/ARCH.ld - - - -This file is the linker script. During preprocessing it includes -linker script fragments that define the memory - layout. - - - - - -<!-- <index></index> -->Platform files - - -ARCH/PLATFORM/&versiondir;/include/hal_diag.h - - - -This file contains the definitions of macros that support -the HAL diagnostic output mechanism. - - - -ARCH/PLATFORM/&versiondir;/include/plf_stub.h - - - -This file contains a set of macros that allow the common GDB -stub code to access the platform-specific minimal serial driver -functions. - - - -ARCH/PLATFORM/&versiondir;/src/hal_diag.c - - - -This file contain the implementation of the HAL diagnostic -output mechanism. - - - -ARCH/PLATFORM/&versiondir;/src/plf_stub.c - - - -This file contains a minimal serial driver for the target -platform that is used by the GDB stub. - - - -ARCH/PLATFORM/&versiondir;/src/PLATFORM.S - - - -This is an assembler file that contains any platform-specific -code. It often contains platform initialization code called from -vectors.S. - - - - - - - -Requirements for programs -eCos programs do not have -to satisfy any unusual requirements, but there are always some differences -between a program written for a real-time operating system as opposed -to one written for a time sharing, virtual memory system like UNIX -or Windows NT. -This chapter contains checklist of things to remember when -writing eCos programs. - -<!-- <index></index> -->cyg_user_start() -The entry point for eCos user programs -is usually cyg_user_start() instead -of main(), although main() can be -used if the ISO C library package is selected. Complete detail on -the start-up sequence is given in . - - -Necessary headers -Any program which uses eCos system calls -must have the following line at the top of the file: -#include <cyg/kernel/kapi.h> -and the programmer must make sure that cyg/kernel/kapi.h is -available in the compiler include path. This can be done by setting -the C_INCLUDE_PATH environment -variable or by including the -I flag on the compiler -command line. - - -Necessary link instructions -The eCos configuration and building process -(described in Getting Started with eCos and eCos User's -Guide) builds a single library, libtarget.a, -which contains the selected eCos components. -The libtarget.a library does not contain -any user libraries: If you put some of your source in libraries, -you will have to explicitly include those libraries in the linking instruction. -You also need to link to the GNU C Compiler runtime -support library (libgcc.a). -You should not link to the standard C++ library. -This can be achieved with the -nostdlib option. -You should only link to libtarget.a and libgcc.a using -the linker script target.ld provided -with eCos. The command line for linking should -look like - -gcc [options] [object files] -Ttarget.ld -nostdlib - - - -<!-- <xref> -->Interrupt and exception handlers -In eCos a distinction is made between - exceptions and - interrupts. - - -exceptions - - -are the result of some action by the currently executing code. -Examples of exceptions are divide by zero, illegal instruction, -bad memory access, etc. - - - -interrupts - - -are the result of a signal source which is conceptually asynchronous -with the currently executing code. Examples of interrupts sources -are the real-time clock, external and on chip peripherals and so -forth. - - - -This distinction is made in the eCos hardware -abstraction layer (HAL) to provide a cleaner and more portable mechanism -for installing interrupt handlers and exception handlers. Individual hardware -platforms can have different ways of naming and handling interrupts, which -is why this abstraction layer was chosen. -Interrupts and exceptions are both associated with vectors, -which are labeled by vector numbers ( and ). -There are distinct spaces for exception and interrupt vectors. -These are called “exception vector numbers” and “interrupt -vector numbers”. System calls which install exception handlers -use the exception vector number, and the system calls which install -interrupt handlers use the interrupt vector number to specify which interrupt -or exception should be handled by the handler. -The details of the vector layout depend on the microprocessor -and interrupt controller, and are documented in the relevant API -sections. -Interrupt handlers are actually a pair of -functions, one of which (the interrupt service routine, -or ISR) is executed immediately and runs with that interrupt disabled. -Since interrupts are disabled for the duration of the ISR, the ISR -should be very brief and should not use any system services. -After the ISR exits, but before the kernel scheduler is invoked -again, a delayed service routine (DSR) will -be invoked. It executes with scheduling disabled, but with interrupts -enabled, so that further invocations of the same DSR can be queued. -The DSR can use some producer-side system calls, but it should be carefully -crafted to avoid using any call that might put its thread to sleep. -One of the few examples of safe calls is cyg_semaphore_post(); -the non-blocking versions of some system calls are also safe. A -call that is unsafe is cyg_mutex_lock(), -since it will block if the mutex is already locked by another thread. -Finally, eCos has a formalism for installing low -level handlers which bypass the kernel mechanisms described -above. A program can install a vector service routine (VSR) -which will be invoked instead of the kernel's usual exception -or interrupt handling. The VSR will typically be written in assembly language. -VSRs are associated with vector numbers in the exception space, -just like exception handlers (although there are some variations — architectures -in which there are no exceptions in the eCos sense). -The main difference between VSRs and exception handlers is that -VSRs bypass the kernel's usual mechanisms. - - -<!-- <index></index> -->Memory allocation -Most eCos system calls expect you to -pass the address of pre-allocated memory for the objects created -in that system call. This is frequently the preferred way of doing things -for embedded applications, where programmers want to allocate all -memory statically and have fine control over that resource. -In contrast, some eCos system calls also -allow a NULL pointer to be passed. In such a case the kernel will allocate -the memory or select default size. This feature is not supported -in the current release, and a warning flag is placed in the documentation -for those routines (like - cyg_thread_create()). -eCos provides dynamic memory allocation, -based on memory pools, a useful and flexible -approach to memory management inspired by the µITRON -compatibility layer. These are described in . -If you configure your system to use the Standard C Library -you can also use the standard malloc() library -call. - - -Assertions and bad parameter handling -This section describes how the eCos kernel -and basic packages behave when system calls are invoked with bad parameters. -In eCos, the basic kernel assertion behavior -is configuration-dependent. -By default, assertions are turned off in the -kernel. If the kernel is configured to turn them on, the -kernel will make basic assertions, such as checking for invalid -parameters when system calls are invoked. If an assertion fails, -the kernel will print a message to the diagnostic output channel -and stop executing. -If the kernel is configured with assertions disabled (usually -when the application has been thoroughly debugged), it will not -do any checking. -The configuration sections referenced above also describe -the use of preconditions, postconditions and loop invariants. These -are no different from ordinary assertions, but they are used in -specialized circumstances, and the programmer would wish to select -their presence individually. - - - -<!-- <xref> -->System start-up -We describe here the steps performed by - eCos upon start-up, mentioning how a - programmer can introduce custom start-up routines. - -System start-up — the HAL -The HAL (Hardware Abstraction Layer, see ) -is the eCos package which contains all start-up -code. Its start-up procedure is outlined in detail in , but the main steps -can be summarized here: - - - The HAL initializes the hardware, coordinates with - the ROM monitor, and performs diagnostics. - - -The HAL invokes all static and global - C++ constructors. - - -The HAL jumps to - cyg_start(), - which has the following prototype: -void cyg_start( void ) - - - - -System start-up — cyg_start() -cyg_start() - is the core -of the start-up mechanism. The default definition -is in infra/current/src/startup.cxx -It calls, in turn, -cyg_prestart() -cyg_package_start() -cyg_user_start() -and then starts the eCos scheduler if -the system has been configured to have a kernel and scheduler. -You can override the default cyg_start() routine -by providing your own function by the same name with the following prototype: -void cyg_start( void ) - -Overriding cyg_start() - should rarely, if ever, be done. The functions - cyg_prestart() and - cyg_user_start() - described just below allow enough flexibility for - installing user initialization code safely for almost all - applications. - - - If you are supplying your own definition of this function - from a C++ file, make sure it has - “C” linkage. - - - - -System startup — cyg_prestart() -The default cyg_prestart() function does - not do anything; it is meant to be overwritten if the - programmer needs to do any initialization - before other system level - initialization. -You can override the default - cyg_prestart() routine by - providing your own function by the same name with the - following prototype: -void cyg_prestart( void ) - - If you are supplying your own definition of this function - from a C++ file, make sure it has - “C” linkage. - - - -System startup — cyg_package_start() -The - cyg_package_start() - allows individual packages to do their initialization before - the main user program is invoked. -Two of the packages shipped with this release of eCos have -code in the default cyg_package_start(); -the µITRON and the ISO standard C -library compatibility packages ( and - ). -The infrastructure package has configuration options CYGSEM_START_UITRON_COMPATIBILITY -and CYGSEM_START_ISO_C_COMPATIBILITY -which control specialized initialization. -You can override the default cyg_package_start() routine -by providing your own function by the same name with the following prototype: -void cyg_package_start( void ) -but you should be careful to initialize the default packages -(if you are using them). An example user-supplied function might -look like: - void cyg_package_start(void) - { - #ifdef CYGSEM_START_UITRON_COMPATABILITY - cyg_uitron_start(); /* keep the µITRON initialization */ - #endif - my_package_start(); /* make sure I initialize my package */ - } - -If you are supplying your own definition of this function -from a C++ file, make sure it has “C” linkage. - - - -System startup — cyg_user_start() -This is the normal entry point for your code. Although a - default empty version is provided by - eCos, this is a good place to set up - your threads (). -If you are not including the ISO standard C library - package then there will not be a - main() function, so it becomes - mandatory to provide this function (). -To set up your own cyg_user_start() -function, create a function by that name with the following prototype: -void cyg_user_start( void ) -When you return control from - cyg_user_start(), - cyg_start() will -then invoke the scheduler, and any threads you created and resumed -in cyg_user_start() will -be executed. The preferred approach is to allow the scheduler to -be started automatically, rather than to start it explicitly in cyg_user_start(). - -Remember that -cyg_user_start() - is invoked before the scheduler (and frequently the scheduler is -invoked as the last step in -cyg_user_start()), so it should not use any - kernel services that require the scheduler. - - - If you are supplying your own definition of this function - from a C++ file, make sure it has - “C” linkage. - - - - -Native kernel C language API -The eCos kernel, like many other - real-time kernels, is a library to which the programmer links - an application. System calls resemble library API calls, and - there is no trap mechanism to switch from user to system mode. - -We present here the eCos kernel -API and the APIs for other kernels provided as compatibility layers -on top of eCos. -Since this API sits on top of a configurable system, the semantics -are only weakly defined. The exact semantics and even the API itself -depend on the configuration. For example if returned error codes -were supported this would change the prototype of the functions. -The semantics given in this chapter describe the default configuration. -As mentioned above, all source files which use the kernel -C API should have the following #include statement: -#include <cyg/kernel/kapi.h> -at the head of the file. - -Types used in programming eCos -We now describe the types defined for use with eCos. -These are available to programs that include kapi.h. - -Most of these types are meant to be opaque — in -other words, programmers do not need to know (and probably should -not know) how they are defined. But the types that are numeric are -marked, since it can be useful to use comparison operators. -The definitions for these types can be found in the installed -tree, in the file include/cyg/kernel/kapi.h. -The eCos kernel uses the following naming -convention for types: - - -Types that can be treated as completely opaque usually -have _t suffix. - - -Types for which it is necessary to know the implementation -do not have a _t suffix. - - - -<!-- <index></index> -->cyg_addrword_t -A type which is large enough to store the larger of an address -and a machine word. This is used for convenience when a function -is passed data which could be either a pointer to a block of data -or a single word. - - -<!-- <index></index> -->cyg_handle_t -A handle is a variable used to refer -to eCos system objects (such as a thread or -an alarm). Most eCos system calls that create -system objects will return a handle that is used to access that -object from then on. - - -<!-- <index></index> -->cyg_priority_t -A numeric type used to represent the priority of a thread, -or the priority of an interrupt level. A lower number means a higher -(i.e. more important) priority thread. - - -<!-- <index></index> -->cyg_code_t -A numeric type used for various error or status codes, such -as exception numbers. - - -<!-- <index></index> -->cyg_vector_t -A numeric type used to identify an interrupt vector. Its value -is called the interrupt vector id. This type -is used for both ISR vector ids and VSR vector ids. - - -<!-- <index></index> -->cyg_tick_count_t -A numeric type used to count counter ticks. The resolution -and other details regarding tick quantities depend on the configuration, -but this is a 64 bit type, and no matter what configuration is chosen -it should still last for centuries before it overflows. - - -<!-- <index></index> -->cyg_bool_t -A boolean type whose values can be false (0) or true (1). - - -<!-- <index></index> -->cyg_thread_entry_t -A function type for functions that are entry points for threads. -It is used in the thread creation call cyg_thread_create(). -To help write thread entry point functions, here is how cyg_thread_entry_t -is defined: -typedef void cyg_thread_entry_t(void *); -Examples of thread functions can be found in the programming -tutorial in Getting Started with eCos. - - -<!-- <index></index> -->cyg_exception_handler_t -A function type used for installing exception handlers. It -is defined as: -typedef void cyg_exception_handler_t( - cyg_addrword_t data, - cyg_code_t exception_number, - cyg_addrword_t info -); - - -<!-- <index></index> -->cyg_thread, <!-- <index></index> --> -cyg_interrupt, <!-- <index></index> --> -cyg_counter, <!-- <index></index> --> -cyg_clock, <!-- <index></index> --> -cyg_alarm, <!-- <index></index> --> -cyg_mbox, <!-- <index></index> --> -cyg_mempool_var, and <!-- <index></index> --> -cyg_mempool_fix -These types are of the appropriate size to contain the memory -used by the respective kernel objects. These types are only used -in the corresponding create call where the programmer allocates -the memory for the object and passes the address to the kernel. -After creation the provided handle is used to reference the object. - - -<!-- <index></index> -->cyg_mempool_info -Contains information about a memory pool. -typedef struct { - cyg_int32 totalmem; - cyg_int32 freemem; - void *base; - cyg_int32 size; - cyg_int32 blocksize; - cyg_int32 maxfree; // The largest free block -} cyg_mempool_info; - - -<!-- <index></index> -->cyg_sem_t, <!-- <index></index> --> -cyg_mutex_t, and <!-- <index></index> --> -cyg_cond_t -These types are of the appropriate size to contain the memory -used by their respective kernel objects. These objects are always -referred to by a pointer to an object of this type. - - -<!-- <index></index> -->cyg_VSR_t, <!-- <index></index> --> -cyg_ISR_t, and <!-- <index></index> --> -cyg_DSR_t -These are function types used when vector, interrupt and delayed -service routines are installed. -typedef void cyg_VSR_t(); -typedef cyg_uint32 cyg_ISR_t(cyg_vector_t vector, - cyg_addrword_t data); -typedef void cyg_DSR_t(cyg_uint32 vector, - cyg_ucount32 count, - cyg_addrword_t data); - - -<!-- <index></index> --><!-- <xref> -->cyg_resolution_t -Stores the resolution of a clock. The resolution is defined -to be (dividend/divisor) nanoseconds per tick. - - typedef struct { cyg_uint32 dividend; cyg_uint32 divisor; } - cyg_resolution_t; - - -<!-- <index></index> -->cyg_alarm_t -The function type used for alarm handlers. - -typedef void cyg_alarm_t(cyg_handle_t alarm, - cyg_addrword_t data); - - - -<!-- <index></index> --><!-- <xref> -->Thread operations -void cyg_scheduler_start( void ) -Starts the scheduler with the threads that have been created. -It never returns. The scheduler has been chosen at configuration -time. eCos currently ships with three schedulers: -a bitmap scheduler, a multi-level scheduler (selected by default), -and an experimental “lottery” scheduler which -is currently incomplete and unusable. -The configuration tool can be used to select between schedulers. -The configuration options are -CYGSEM_SCHED_BITMAP, CYGSEM_SCHED_MLQUEUE - and CYGSEM_SCHED_LOTTERY. - - Interrupts are not enabled until the scheduler has been - started with - cyg_scheduler_start(). - -void cyg_scheduler_lock( void ) -Locks the scheduler so that a context switch cannot occur. -This can be used to protect data shared between a thread and a DSR, -or between multiple threads, by surrounding the critical region -with cyg_scheduler_lock() and cyg_scheduler_unlock(). -void cyg_scheduler_unlock( void ) -Unlocks the scheduler so that context switching can - occur again. - -void cyg_thread_create( - cyg_addrword_t sched_info, - cyg_thread_entry_t *entry, - cyg_addrword_t entry_data, - char *name, - void *stack_base, - cyg_ucount32 stack_size, - cyg_handle_t *handle, - cyg_thread *thread ) -Creates a thread in a suspended state. The thread will not -run until it has been resumed with cyg_thread_resume() and -the scheduler has been started with cyg_scheduler_start(). -Here is a description of the parameters of - cyg_thread_create(): - - -sched_info - - -Information to be passed to the scheduler. For almost all -schedulers this is a simple priority value, and you can simply pass -a non-negative integer when you create the thread. Even when this -holds, some schedulers may have restrictions on how priorities can -be used. For example, the bitmap scheduler can onlyhave one thread at -each priority, so if an already-occupied priority slot is quoted, -the next free slot of lower priority is chosen. - - - -entry - - -A user-supplied function: it is a routine that begins execution -of the new thread. This function takes a single argument of type -cyg_addrword_t, which is usually a pointer to -a block of data, which allows cyg_scheduler_start() to -pass data to this particular thread. -Here is a typedef for the entry function: -typedef void cyg_thread_entry_t(cyg_addrword_t); - - - -entry_data - - -A data value passed to the entry function. This may be either -a machine word datum or the address of a block of - data. - - - -name - - -A C string with the name of this thread. - - - -stack_base - - -The address of the stack base. If this value is NULL then - cyg_thread_create() will choose a stack - base. - -Passing a stack base of NULL is not supported in - this release. You must pass a real address for the - stack base. - - - - -stack_size - - -The size of the stack for this thread. If this is 0, the default -stack size will be used for this thread. - -Passing a stack size of 0 is not supported in this release. - You must pass a real stack size. - - - - -handle - - -cyg_thread_create() returns -the thread handle in this location. - - - -thread - - -The thread housekeeping information is placed in the memory -pointed to by this parameter. If this pointer is NULL then the memory -will be allocated. - - - - -Passing a NULL value for the thread data structure - address is not supported in this release. You must pass a - valid address. - -void cyg_thread_exit( void ) -Exits the current thread. At present this simply puts the -thread into suspended state. -void cyg_thread_suspend ( cyg_handle_t thread ) -Suspends the thread. A thread may be suspended multiple times, -in which case it will need to be resumed the same number of times -before it will run. A thread can suspend itself; the effect will -be that the call does not return until some other thread has resumed -it. Obviously this can only be done once! -It is OK for a thread to suspend other threads with the scheduler -locked; it will continue to run until the scheduler is unlocked. - However, a thread suspending itself with the scheduler locked is -in danger of causing problems within the system because a suspended -thread has been removed from its run-queue, even if it continues -to execute! The problematic situation cannot be detected because -it is OK for a DSR (ie. alarm function for example) to suspend -a thread - possibly the current thread if that is what happened -to be running, and DSRs run with the scheduler locked. -If you see an assert referring to something like "Queue map -bit not set for pri" it is likely that this means a thread has suspended -itself with the scheduler locked. The simplest workaround is: never -let a thread suspend itself; look for that behaviour in your code. - -void cyg_thread_resume ( cyg_handle_t thread ) - -Resumes thread. If a thread has been suspended multiple times -it will need to be resumed the same number of times before it will -run. Threads are created in a suspended state and must be resumed -before they will run. -void cyg_thread_yield ( void ) -Yields control to the next runnable thread of equal - priority. If no such thread exists, then this function has - no effect. -void cyg_thread_kill ( cyg_handle_t thread ) -Kills thread. -cyg_bool_t cyg_thread_delete( cyg_handle_t thread) -Kills thread and deletes it from the -scheduler. If necessary, it will kill thread - first using cyg_thread_kill( thread ). -If thread does not terminate in response to -the kill message, this function returns false, indicating failure. -This function differs from cyg_thread_kill() (or -calling cyg_thread_exit() -for the current thread) by deregistering the thread from the -scheduler. As a result, the thread handle, thread stack and space -passed for the thread housekeeping information can then be reused. -This is not the case if just cyg_thread_kill() or cyg_thread_exit() is -invoked for the thread. - -cyg_thread_delete() - only deregisters the thread from the scheduler, it does not free -up any resources that had been allocated by the thread such as dynamic -memory, nor does it unlock any synchronization objects owned by -the thread. This is the responsibility of the programmer. Additionally, -unlike -cyg_thread_kill(), the -cyg_thread_delete() - function cannot be self-referencing. - - -// Delete another thread. This must be done in a loop, waiting -// for the call to return true. If it returns false, go to sleep -// for a while, so that the killed thread gets a chance to run -// and complete its business. -while (!cyg_thread_delete(<thread_handle>) { - cyg_thread_delay(1); - - cyg_handle_t cyg_thread_self( void ) -Returns the handle of the current thread. -void cyg_thread_release ( cyg_handle_t thread ) -Break the thread out of any wait it is currently in. - Exactly how the thread returns from the wait operation, and - how, if at all, the break is indicated, depends on the - synchronization object it was waiting on. -cyg_ucount32 cyg_thread_new_data_index ( void ) -Allocates a new per-thread data index from those still - available. If no more indexes are available, and assertions - are enabled, an assertion will be raised. -void cyg_thread_free_data_index ( cyg_ucount32 index ) -Return the per-thread data index to the pool. -CYG_ADDRWORD cyg_thread_get_data( cyg_ucount32 index ) -Retrieve the per-thread data at the given index for the current -thread. -CYG_ADDRWORD *cyg_thread_get_data_ptr( cyg_ucount32 index ) -Return a pointer to the per-thread data at the given index -for the current thread. This should be used with some care since -in some future implementation the per-thread data may be managed -by a dynamic mechanism that might invalidate this pointer at any -time. This pointer should only be considered valid until the next call -to the per-thread data functions. -void cyg_thread_set_data( cyg_ucount32 index, CYG_ADDRWORD data ) -Store the data in the per-thread data for the current thread -at the given index. - - -<!-- <index></index> -->Priority manipulation -void cyg_thread_set_priority( cyg_handle_t thread, cyg_priority_t priority ) -Sets the priority of the given thread to the given value. -The smaller the value, the higher the priority of the thread. -Allowed priorities range between 1 and 64. The values of these -parameters are configuration-dependent because they depend on which -scheduler has been selected, and what value has been configured -for the CYGNUM_KERNEL_SCHED_PRIORITIES -configuration parameter (). -There is always an idle thread, owned by the kernel, running -at CYG_THREAD_MIN_PRIORITY. Because of -this, ordinary threads should never be run at the lowest priority. -cyg_priority_t cyg_thread_get_priority( cyg_handle_t thread ) -Returns the priority of the given thread. -void cyg_thread_delay( cyg_tick_count_t delay ) -Puts the current thread to sleep for delay ticks. In a default -configuration there are approximately 100 ticks a second. The actual -length of the ticks is given by the resolution of the real-time -clock. for more -information on counter resolution. - - -<!-- <index></index> --><!-- <xref> -->Exception handling -Exception handlers can be installed to deal with various system-level -exceptions, such as alignment errors, resets, timers and so forth. -Exception handling is a configurable feature of eCos and -is enabled by default. -The range of values for the exception_number parameter -in the functions below is hardware-dependent, as are the individual -exceptions. See hal/ARCH/arch/&versiondir;/include/hal_intr for -the exception vector definitions specific to a given architecture. -The exception handler is a function of the following type: -typedef void cyg_exception_handler_t( - cyg_addrword_t data, - cyg_code_t exception_number, - cyg_addrword_t info -); -cyg_exception_handler_t is the -type used for functions which are called as a result of an exception. -It is used in the function cyg_exception_set_handler(). -void cyg_exception_set_handler( - cyg_code_t exception_number, - cyg_exception_handler_t *new_handler, - cyg_addrword_t new_data, cyg_exception_handler_t **old_handler, - void **old_data -) -Replace current exception handler. This may apply to either -the thread, or to a global exception handler, according to how exception -handling was configured (global or per-thread). The exception may -be ignored, or used to specify a particular handler. -void cyg_exception_call_handler ( - cyg_handle_t thread, - cyg_code_t exception_number, - cyg_addrword_t exception_info -) -Invoke exception handler for the given exception number. The -exception handler will be invoked with exception_info as -its third argument. - - -<!-- <index></index> --><!-- <xref> -->Interrupt handling -Interrupt handling is by nature machine-specific. The eCos kernel -aims to provide efficiency and flexibility in this area, while maintaining -a very low interrupt latency. To allow the programmer direct access -to hardware, the semantics and the interface can vary from one architecture -to another. -The interrupt vectors for a given architecture are defined -in hal/ARCH/arch/&versiondir;/include/hal_intr.h where -also special semantics and caveats of the interrupt capabilities -would be described. -typedef void cyg_VSR_t(); -typedef cyg_uint32 cyg_ISR_t(cyg_vector_t vector, - cyg_addrword_t data); -typedef void cyg_DSR_t(cyg_vector_t vector, - cyg_ucount32 count, - cyg_addrword_t data); - -enum cyg_ISR_results + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The eCos Kernel + + + + + + + Kernel Overview + + + + Kernel + Overview of the eCos Kernel + + + + + + Description + +The kernel is one of the key packages in all of eCos. It provides the +core functionality needed for developing multi-threaded applications: + + + +The ability to create new threads in the system, either during startup +or when the system is already running. + + +Control over the various threads in the system, for example +manipulating their priorities. + + +A choice of schedulers, determining which thread should currently be +running. + + +A range of synchronization primitives, allowing threads to interact +and share data safely. + + +Integration with the system's support for interrupts and exceptions. + + + +In some other operating systems the kernel provides additional +functionality. For example the kernel may also provide memory +allocation functionality, and device drivers may be part of the kernel +as well. This is not the case for eCos. Memory allocation is handled +by a separate package. Similary each device driver will typically be a +separate package. Various packages are combined and configured using +the eCos configuration technology to meet the requirements of the +application. + + +The eCos kernel package is optional. It is possible to write +single-threaded applications which do not use any kernel +functionality, for example RedBoot. Typically such applications are +based around a central polling loop, continually checking all devices +and taking appropriate action when I/O occurs. A small amount of +calculation is possible every iteration, at the cost of an increased +delay between an I/O event occurring and the polling loop detecting +the event. When the requirements are straightforward it may well be +easier to develop the application using a polling loop, avoiding the +complexities of multiple threads and synchronization between threads. +As requirements get more complicated a multi-threaded solution becomes +more appropriate, requiring the use of the kernel. In fact some of the +more advanced packages in eCos, for example the TCP/IP stack, use +multi-threading internally. Therefore if the application uses any of +those packages then the kernel becomes a required package, not an +optional one. + + +The kernel functionality can be used in one of two ways. The kernel +provides its own C API, with functions like +cyg_thread_create and +cyg_mutex_lock. These can be called directly from +application code or from other packages. Alternatively there are a +number of packages which provide compatibility with existing API's, +for example POSIX threads or µITRON. These allow application +code to call standard functions such as +pthread_create, and those functions are +implemented using the basic functionality provided by the eCos kernel. +Using compatibility packages in an eCos application can make it much +easier to reuse code developed in other environments, and to share +code. + + +Although the different compatibility packages have similar +requirements on the underlying kernel, for example the ability to +create a new thread, there are differences in the exact semantics. For +example, strict µITRON compliance requires that kernel +timeslicing is disabled. This is achieved largely through the +configuration technology. The kernel provides a number of +configuration options that control the exact semantics that are +provided, and the various compatibility packages require particular +settings for those options. This has two important consequences. +First, it is not usually possible to have two different compatibility +packages in one eCos configuration because they will have conflicting +requirements on the underlying kernel. Second, the semantics of the +kernel's own API are only loosely defined because of the many +configuration options. For example cyg_mutex_lock +will always attempt to lock a mutex, but various configuration options +determine the behaviour when the mutex is already locked and there is +a possibility of priority inversion. + + +The optional nature of the kernel package presents some complications +for other code, especially device drivers. Wherever possible a device +driver should work whether or not the kernel is present. However there +are some parts of the system, especially those related to interrupt +handling, which should be implemented differently in multi-threaded +environments containing the eCos kernel and in single-threaded +environments without the kernel. To cope with both scenarios the +common HAL package provides a driver API, with functions such as +cyg_drv_interrupt_attach. When the kernel package +is present these driver API functions map directly on to the +equivalent kernel functions such as +cyg_interrupt_attach, using macros to avoid any +overheads. When the kernel is absent the common HAL package implements +the driver API directly, but this implementation is simpler than the +one in the kernel because it can assume a single-threaded environment. + + + + + + + + Schedulers + +When a system involves multiple threads, a scheduler is needed to +determine which thread should currently be running. The eCos kernel +can be configured with one of two schedulers, the bitmap scheduler and +the multi-level queue (MLQ) scheduler. The bitmap scheduler is +somewhat more efficient, but has a number of limitations. Most systems +will instead use the MLQ scheduler. Other schedulers may be added in +the future, either as extensions to the kernel package or in separate +packages. + + +Both the bitmap and the MLQ scheduler use a simple numerical priority +to determine which thread should be running. The number of priority +levels is configurable via the option +CYGNUM_KERNEL_SCHED_PRIORITIES, but a typical +system will have up to 32 priority levels. Therefore thread priorities +will be in the range 0 to 31, with 0 being the highest priority and 31 +the lowest. Usually only the system's idle thread will run at the +lowest priority. Thread priorities are absolute, so the kernel will +only run a lower-priority thread if all higher-priority threads are +currently blocked. + + +The bitmap scheduler only allows one thread per priority level, so if +the system is configured with 32 priority levels then it is limited to +only 32 threads — still enough for many applications. A simple +bitmap can be used to keep track of which threads are currently +runnable. Bitmaps can also be used to keep track of threads waiting on +a mutex or other synchronization primitive. Identifying the +highest-priority runnable or waiting thread involves a simple +operation on the bitmap, and an array index operation can then be used +to get hold of the thread data structure itself. This makes the +bitmap scheduler fast and totally deterministic. + + +The MLQ scheduler allows multiple threads to run at the same priority. +This means that there is no limit on the number of threads in the +system, other than the amount of memory available. However operations +such as finding the highest priority runnable thread are a little bit +more expensive than for the bitmap scheduler. + + +Optionally the MLQ scheduler supports timeslicing, where the scheduler +automatically switches from one runnable thread to another when some +number of clock ticks have occurred. Timeslicing only comes into play +when there are two runnable threads at the same priority and no higher +priority runnable threads. If timeslicing is disabled then a thread +will not be preempted by another thread of the same priority, and will +continue running until either it explicitly yields the processor or +until it blocks by, for example, waiting on a synchronization +primitive. The configuration options +CYGSEM_KERNEL_SCHED_TIMESLICE and +CYGNUM_KERNEL_SCHED_TIMESLICE_TICKS control +timeslicing. The bitmap scheduler does not provide timeslicing +support. It only allows one thread per priority level, so it is not +possible to preempt the current thread in favour of another one with +the same priority. + + +Another important configuration option that affects the MLQ scheduler +is CYGIMP_KERNEL_SCHED_SORTED_QUEUES. This +determines what happens when a thread blocks, for example by waiting +on a semaphore which has no pending events. The default behaviour of +the system is last-in-first-out queuing. For example if several +threads are waiting on a semaphore and an event is posted, the thread +that gets woken up is the last one that called +cyg_semaphore_wait. This allows for a simple and +fast implementation of both the queue and dequeue operations. However +if there are several queued threads with different priorities, it may +not be the highest priority one that gets woken up. In practice this +is rarely a problem: usually there will be at most one thread waiting +on a queue, or when there are several threads they will be of the same +priority. However if the application does require strict priority +queueing then the option +CYGIMP_KERNEL_SCHED_SORTED_QUEUES should be +enabled. There are disadvantages: more work is needed whenever a +thread is queued, and the scheduler needs to be locked for this +operation so the system's dispatch latency is worse. If the bitmap +scheduler is used then priority queueing is automatic and does not +involve any penalties. + + +Some kernel functionality is currently only supported with the MLQ +scheduler, not the bitmap scheduler. This includes support for SMP +systems, and protection against priority inversion using either mutex +priority ceilings or priority inheritance. + + + + + + + + Synchronization Primitives + +The eCos kernel provides a number of different synchronization +primitives: mutexes, +condition variables, +counting semaphores, +mail boxes and +event flags. + + +Mutexes serve a very different purpose from the other primitives. A +mutex allows multiple threads to share a resource safely: a thread +locks a mutex, manipulates the shared resource, and then unlocks the +mutex again. The other primitives are used to communicate information +between threads, or alternatively from a DSR associated with an +interrupt handler to a thread. + + +When a thread that has locked a mutex needs to wait for some condition +to become true, it should use a condition variable. A condition +variable is essentially just a place for a thread to wait, and which +another thread, or DSR, can use to wake it up. When a thread waits on +a condition variable it releases the mutex before waiting, and when it +wakes up it reacquires it before proceeding. These operations are +atomic so that synchronization race conditions cannot be introduced. + + +A counting semaphore is used to indicate that a particular event has +occurred. A consumer thread can wait for this event to occur, and a +producer thread or a DSR can post the event. There is a count +associated with the semaphore so if the event occurs multiple times in +quick succession this information is not lost, and the appropriate +number of semaphore wait operations will succeed. + + +Mail boxes are also used to indicate that a particular event has +occurred, and allows for one item of data to be exchanged per event. +Typically this item of data would be a pointer to some data structure. +Because of the need to store this extra data, mail boxes have a +finite capacity. If a producer thread generates mail box events +faster than they can be consumed then, to avoid overflow, it will be +blocked until space is again available in the mail box. This means +that mail boxes usually cannot be used by a DSR to wake up a +thread. Instead mail boxes are typically only used between threads. + + +Event flags can be used to wait on some number of different events, +and to signal that one or several of these events have occurred. This +is achieved by associating bits in a bit mask with the different +events. Unlike a counting semaphore no attempt is made to keep track +of the number of events that have occurred, only the fact that an +event has occurred at least once. Unlike a mail box it is not +possible to send additional data with the event, but this does mean +that there is no possibility of an overflow and hence event flags can +be used between a DSR and a thread as well as between threads. + + +The eCos common HAL package provides its own device driver API which +contains some of the above synchronization primitives. These allow +the DSR for an interrupt handler to signal events to higher-level +code. If the configuration includes the eCos kernel package then +the driver API routines map directly on to the equivalent kernel +routines, allowing interrupt handlers to interact with threads. If the +kernel package is not included and the application consists of just a +single thread running in polled mode then the driver API is +implemented entirely within the common HAL, and with no need to worry +about multiple threads the implementation can obviously be rather +simpler. + + + + + + + + Threads and Interrupt Handling + +During normal operation the processor will be running one of the +threads in the system. This may be an application thread, a system +thread running inside say the TCP/IP stack, or the idle thread. From +time to time a hardware interrupt will occur, causing control to be +transferred briefly to an interrupt handler. When the interrupt has +been completed the system's scheduler will decide whether to return +control to the interrupted thread or to some other runnable thread. + + +Threads and interrupt handlers must be able to interact. If a thread +is waiting for some I/O operation to complete, the interrupt handler +associated with that I/O must be able to inform the thread that the +operation has completed. This can be achieved in a number of ways. One +very simple approach is for the interrupt handler to set a volatile +variable. A thread can then poll continuously until this flag is set, +possibly sleeping for a clock tick in between. Polling continuously +means that the cpu time is not available for other activities, which +may be acceptable for some but not all applications. Polling once +every clock tick imposes much less overhead, but means that the thread +may not detect that the I/O event has occurred until an entire clock +tick has elapsed. In typical systems this could be as long as 10 +milliseconds. Such a delay might be acceptable for some applications, +but not all. + + +A better solution would be to use one of the synchronization +primitives. The interrupt handler could signal a condition variable, +post to a semaphore, or use one of the other primitives. The thread +would perform a wait operation on the same primitive. It would not +consume any cpu cycles until the I/O event had occurred, and when the +event does occur the thread can start running again immediately +(subject to any higher priority threads that might also be runnable). + + +Synchronization primitives constitute shared data, so care must be +taken to avoid problems with concurrent access. If the thread that was +interrupted was just performing some calculations then the interrupt +handler could manipulate the synchronization primitive quite safely. +However if the interrupted thread happened to be inside some kernel +call then there is a real possibility that some kernel data structure +will be corrupted. + + +One way of avoiding such problems would be for the kernel functions to +disable interrupts when executing any critical region. On most +architectures this would be simple to implement and very fast, but it +would mean that interrupts would be disabled often and for quite a +long time. For some applications that might not matter, but many +embedded applications require that the interrupt handler run as soon +as possible after the hardware interrupt has occurred. If the kernel +relied on disabling interrupts then it would not be able to support +such applications. + + +Instead the kernel uses a two-level approach to interrupt handling. +Associated with every interrupt vector is an Interrupt Service Routine +or ISR, which will run as quickly as possible so that it can service +the hardware. However an ISR can make only a small number of kernel +calls, mostly related to the interrupt subsystem, and it cannot make +any call that would cause a thread to wake up. If an ISR detects that +an I/O operation has completed and hence that a thread should be woken +up, it can cause the associated Deferred Service Routine or DSR to +run. A DSR is allowed to make more kernel calls, for example it can +signal a condition variable or post to a semaphore. + + +Disabling interrupts prevents ISRs from running, but very few parts of +the system disable interrupts and then only for short periods of time. +The main reason for a thread to disable interrupts is to manipulate +some state that is shared with an ISR. For example if a thread needs +to add another buffer to a linked list of free buffers and the ISR may +remove a buffer from this list at any time, the thread would need to +disable interrupts for the few instructions needed to manipulate the +list. If the hardware raises an interrupt at this time, it remains +pending until interrupts are reenabled. + + +Analogous to interrupts being disabled or enabled, the kernel has a +scheduler lock. The various kernel functions such as +cyg_mutex_lock and +cyg_semaphore_post will claim the scheduler lock, +manipulate the kernel data structures, and then release the scheduler +lock. If an interrupt results in a DSR being requested and the +scheduler is currently locked, the DSR remains pending. When the +scheduler lock is released any pending DSRs will run. These may post +events to synchronization primitives, causing other higher priority +threads to be woken up. + + +For an example, consider the following scenario. The system has a high +priority thread A, responsible for processing some data coming from an +external device. This device will raise an interrupt when data is +available. There are two other threads B and C which spend their time +performing calculations and occasionally writing results to a display +of some sort. This display is a shared resource so a mutex is used to +control access. + + +At a particular moment in time thread A is likely to be blocked, +waiting on a semaphore or another synchronization primitive until data +is available. Thread B might be running performing some calculations, +and thread C is runnable waiting for its next timeslice. Interrupts +are enabled, and the scheduler is unlocked because none of the threads +are in the middle of a kernel operation. At this point the device +raises an interrupt. The hardware transfers control to a low-level +interrupt handler provided by eCos which works out exactly which +interrupt occurs, and then the corresponding ISR is run. This ISR +manipulates the hardware as appropriate, determines that there is now +data available, and wants to wake up thread A by posting to the +semaphore. However ISR's are not allowed to call +cyg_semaphore_post directly, so instead the ISR +requests that its associated DSR be run and returns. There are no more +interrupts to be processed, so the kernel next checks for DSR's. One +DSR is pending and the scheduler is currently unlocked, so the DSR can +run immediately and post the semaphore. This will have the effect of +making thread A runnable again, so the scheduler's data structures are +adjusted accordingly. When the DSR returns thread B is no longer the +highest priority runnable thread so it will be suspended, and instead +thread A gains control over the cpu. + + +In the above example no kernel data structures were being manipulated +at the exact moment that the interrupt happened. However that cannot +be assumed. Suppose that thread B had finished its current set of +calculations and wanted to write the results to the display. It would +claim the appropriate mutex and manipulate the display. Now suppose +that thread B was timesliced in favour of thread C, and that thread C +also finished its calculations and wanted to write the results to the +display. It would call cyg_mutex_lock. This +kernel call locks the scheduler, examines the current state of the +mutex, discovers that the mutex is already owned by another thread, +suspends the current thread, and switches control to another runnable +thread. Another interrupt happens in the middle of this +cyg_mutex_lock call, causing the ISR to run +immediately. The ISR decides that thread A should be woken up so it +requests that its DSR be run and returns back to the kernel. At this +point there is a pending DSR, but the scheduler is still locked by the +call to cyg_mutex_lock so the DSR cannot run +immediately. Instead the call to cyg_mutex_lock +is allowed to continue, which at some point involves unlocking the +scheduler. The pending DSR can now run, safely post the semaphore, and +thus wake up thread A. + + +If the ISR had called cyg_semaphore_post directly +rather than leaving it to a DSR, it is likely that there would have +been some sort of corruption of a kernel data structure. For example +the kernel might have completely lost track of one of the threads, and +that thread would never have run again. The two-level approach to +interrupt handling, ISR's and DSR's, prevents such problems with no +need to disable interrupts. + + + + + + + + Calling Contexts + +eCos defines a number of contexts. Only certain calls are allowed from +inside each context, for example most operations on threads or +synchronization primitives are not allowed from ISR context. The +different contexts are initialization, thread, ISR and DSR. + + +When eCos starts up it goes through a number of phases, including +setting up the hardware and invoking C++ static constructors. During +this time interrupts are disabled and the scheduler is locked. When a +configuration includes the kernel package the final operation is a +call to cyg_scheduler_start. +At this point interrupts are enabled, the scheduler is unlocked, and +control is transferred to the highest priority runnable thread. If the +configuration also includes the C library package then usually the C +library startup package will have created a thread which will call the +application's main entry point. + + +Some application code can also run before the scheduler is started, +and this code runs in initialization context. If the application is +written partly or completely in C++ then the constructors for any +static objects will be run. Alternatively application code can define +a function cyg_user_start which gets called after +any C++ static constructors. This allows applications to be written +entirely in C. + + +void +cyg_user_start(void) +{ + /* Perform application-specific initialization here */ +} + + +It is not necessary for applications to provide a +cyg_user_start function since the system will +provide a default implementation which does nothing. + + +Typical operations that are performed from inside static constructors +or cyg_user_start include creating threads, +synchronization primitives, setting up alarms, and registering +application-specific interrupt handlers. In fact for many applications +all such creation operations happen at this time, using statically +allocated data, avoiding any need for dynamic memory allocation or +other overheads. + + +Code running in initialization context runs with interrupts disabled +and the scheduler locked. It is not permitted to reenable interrupts +or unlock the scheduler because the system is not guaranteed to be in +a totally consistent state at this point. A consequence is that +initialization code cannot use synchronization primitives such as +cyg_semaphore_wait to wait for an external event. +It is permitted to lock and unlock a mutex: there are no other threads +running so it is guaranteed that the mutex is not yet locked, and +therefore the lock operation will never block; this is useful when +making library calls that may use a mutex internally. + + +At the end of the startup sequence the system will call +cyg_scheduler_start and the various threads will +start running. In thread context nearly all of the kernel functions +are available. There may be some restrictions on interrupt-related +operations, depending on the target hardware. For example the hardware +may require that interrupts be acknowledged in the ISR or DSR before +control returns to thread context, in which case +cyg_interrupt_acknowledge should not be called +by a thread. + + +At any time the processor may receive an external interrupt, causing +control to be transferred from the current thread. Typically a VSR +provided by eCos will run and determine exactly which interrupt +occurred. Then the VSR will switch to the appropriate ISR, which can +be provided by a HAL package, a device driver, or by the application. +During this time the system is running at ISR context, and most of the +kernel function calls are disallowed. This includes the various +synchronization primitives, so for example an ISR is not allowed to +post to a semaphore to indicate that an event has happened. Usually +the only operations that should be performed from inside an ISR are +ones related to the interrupt subsystem itself, for example masking an +interrupt or acknowledging that an interrupt has been processed. On +SMP systems it is also possible to use spinlocks from ISR context. + + +When an ISR returns it can request that the corresponding DSR be run +as soon as it is safe to do so, and that will run in DSR context. This +context is also used for running alarm functions, and threads can +switch temporarily to DSR context by locking the scheduler. Only +certain kernel functions can be called from DSR context, although more +than in ISR context. In particular it is possible to use any +synchronization primitives which cannot block. These include +cyg_semaphore_post, +cyg_cond_signal, +cyg_cond_broadcast, +cyg_flag_setbits, and +cyg_mbox_tryput. It is not possible to use any +primitives that may block such as +cyg_semaphore_wait, +cyg_mutex_lock, or +cyg_mbox_put. Calling such functions from inside +a DSR may cause the system to hang. + + +The specific documentation for the various kernel functions gives more +details about valid contexts. + + + + + + + + Error Handling and Assertions + +In many APIs each function is expected to perform some validation of +its parameters and possibly of the current state of the system. This +is supposed to ensure that each function is used correctly, and that +application code is not attempting to perform a semaphore operation on +a mutex or anything like that. If an error is detected then a suitable +error code is returned, for example the POSIX function +pthread_mutex_lock can return various error codes +including EINVAL and EDEADLK. +There are a number of problems with this approach, especially in the +context of deeply embedded systems: + + + +Performing these checks inside the mutex lock and all the other +functions requires extra cpu cycles and adds significantly to the code +size. Even if the application is written correctly and only makes +system function calls with sensible arguments and under the right +conditions, these overheads still exist. + + +Returning an error code is only useful if the calling code detects +these error codes and takes appropriate action. In practice the +calling code will often ignore any errors because the programmer +“knows” that the function is being +used correctly. If the programmer is mistaken then an error condition +may be detected and reported, but the application continues running +anyway and is likely to fail some time later in mysterious ways. + + +If the calling code does always check for error codes, that adds yet +more cpu cycles and code size overhead. + + +Usually there will be no way to recover from certain errors, so if the +application code detected an error such as EINVAL +then all it could do is abort the application somehow. + + + +The approach taken within the eCos kernel is different. Functions such +as cyg_mutex_lock will not return an error code. +Instead they contain various assertions, which can be enabled or +disabled. During the development process assertions are normally left +enabled, and the various kernel functions will perform parameter +checks and other system consistency checks. If a problem is detected +then an assertion failure will be reported and the application will be +terminated. In a typical debug session a suitable breakpoint will have +been installed and the developer can now examine the state of the +system and work out exactly what is going on. Towards the end of the +development cycle assertions will be disabled by manipulating +configuration options within the eCos infrastructure package, and all +assertions will be eliminated at compile-time. The assumption is that +by this time the application code has been mostly debugged: the +initial version of the code might have tried to perform a semaphore +operation on a mutex, but any problems like that will have been fixed +some time ago. This approach has a number of advantages: + + + +In the final application there will be no overheads for checking +parameters and other conditions. All that code will have been +eliminated at compile-time. + + +Because the final application will not suffer any overheads, it is +reasonable for the system to do more work during the development +process. In particular the various assertions can test for more error +conditions and more complicated errors. When an error is detected +it is possible to give a text message describing the error rather than +just return an error code. + + +There is no need for application programmers to handle error codes +returned by various kernel function calls. This simplifies the +application code. + + +If an error is detected then an assertion failure will be reported +immediately and the application will be halted. There is no +possibility of an error condition being ignored because application +code did not check for an error code. + + + +Although none of the kernel functions return an error code, many of +them do return a status condition. For example the function +cyg_semaphore_timed_wait waits until either an +event has been posted to a semaphore, or until a certain number of +clock ticks have occurred. Usually the calling code will need to know +whether the wait operation succeeded or whether a timeout occurred. +cyg_semaphore_timed_wait returns a boolean: a +return value of zero or false indicates a timeout, a non-zero return +value indicates that the wait succeeded. + + +In conventional APIs one common error conditions is lack of memory. +For example the POSIX function pthread_create +usually has to allocate some memory dynamically for the thread stack +and other per-thread data. If the target hardware does not have enough +memory to meet all demands, or more commonly if the application +contains a memory leak, then there may not be enough memory available +and the function call would fail. The eCos kernel avoids such problems +by never performing any dynamic memory allocation. Instead it is the +responsibility of the application code to provide all the memory +required for kernel data structures and other needs. In the case of +cyg_thread_create this means a +cyg_thread data structure to hold the thread +details, and a char array for the thread stack. + + +In many applications this approach results in all data structures +being allocated statically rather than dynamically. This has several +advantages. If the application is in fact too large for the target +hardware's memory then there will be an error at link-time rather than +at run-time, making the problem much easier to diagnose. Static +allocation does not involve any of the usual overheads associated with +dynamic allocation, for example there is no need to keep track of the +various free blocks in the system, and it may be possible to eliminate +malloc from the system completely. Problems such +as fragmentation and memory leaks cannot occur if all data is +allocated statically. However, some applications are sufficiently +complicated that dynamic memory allocation is required, and the +various kernel functions do not distinguish between statically and +dynamically allocated memory. It still remains the responsibility of +the calling code to ensure that sufficient memory is available, and +passing null pointers to the kernel will result in assertions or +system failure. + + + + + + + + + + + + + + SMP Support + + + + SMP + Support Symmetric Multiprocessing Systems + + + + Description + +eCos contains support for limited Symmetric Multi-Processing (SMP). +This is only available on selected architectures and platforms. +The implementation has a number of restrictions on the kind of +hardware supported. These are described in . + + + +The following sections describe the changes that have been made to the +eCos kernel to support SMP operation. + + + + + System Startup + +The system startup sequence needs to be somewhat different on an SMP +system, although this is largely transparent to application code. The +main startup takes place on only one CPU, called the primary CPU. All +other CPUs, the secondary CPUs, are either placed in suspended state +at reset, or are captured by the HAL and put into a spin as they start +up. The primary CPU is responsible for copying the DATA segment and +zeroing the BSS (if required), calling HAL variant and platform +initialization routines and invoking constructors. It then calls +cyg_start to enter the application. The +application may then create extra threads and other objects. + + +It is only when the application calls +cyg_scheduler_start that the secondary CPUs are +initialized. This routine scans the list of available secondary CPUs +and invokes HAL_SMP_CPU_START to start each +CPU. Finally it calls an internal function +Cyg_Scheduler::start_cpu to enter the scheduler +for the primary CPU. + + +Each secondary CPU starts in the HAL, where it completes any per-CPU +initialization before calling into the kernel at +cyg_kernel_cpu_startup. Here it claims the +scheduler lock and calls +Cyg_Scheduler::start_cpu. + + +Cyg_Scheduler::start_cpu is common to both the +primary and secondary CPUs. The first thing this code does is to +install an interrupt object for this CPU's inter-CPU interrupt. From +this point on the code is the same as for the single CPU case: an +initial thread is chosen and entered. + + +From this point on the CPUs are all equal, eCos makes no further +distinction between the primary and secondary CPUs. However, the +hardware may still distinguish between them as far as interrupt +delivery is concerned. + + + + + Scheduling + +To function correctly an operating system kernel must protect its +vital data structures, such as the run queues, from concurrent +access. In a single CPU system the only concurrent activities to worry +about are asynchronous interrupts. The kernel can easily guard its +data structures against these by disabling interrupts. However, in a +multi-CPU system, this is inadequate since it does not block access by +other CPUs. + + +The eCos kernel protects its vital data structures using the scheduler +lock. In single CPU systems this is a simple counter that is +atomically incremented to acquire the lock and decremented to release +it. If the lock is decremented to zero then the scheduler may be +invoked to choose a different thread to run. Because interrupts may +continue to be serviced while the scheduler lock is claimed, ISRs are +not allowed to access kernel data structures, or call kernel routines +that can. Instead all such operations are deferred to an associated +DSR routine that is run during the lock release operation, when the +data structures are in a consistent state. + + +By choosing a kernel locking mechanism that does not rely on interrupt +manipulation to protect data structures, it is easier to convert eCos +to SMP than would otherwise be the case. The principal change needed to +make eCos SMP-safe is to convert the scheduler lock into a nestable +spin lock. This is done by adding a spinlock and a CPU id to the +original counter. + + +The algorithm for acquiring the scheduler lock is very simple. If the +scheduler lock's CPU id matches the current CPU then it can just increment +the counter and continue. If it does not match, the CPU must spin on +the spinlock, after which it may increment the counter and store its +own identity in the CPU id. + + +To release the lock, the counter is decremented. If it goes to zero +the CPU id value must be set to NONE and the spinlock cleared. + + +To protect these sequences against interrupts, they must be performed +with interrupts disabled. However, since these are very short code +sequences, they will not have an adverse effect on the interrupt +latency. + + +Beyond converting the scheduler lock, further preparing the kernel for +SMP is a relatively minor matter. The main changes are to convert +various scalar housekeeping variables into arrays indexed by CPU +id. These include the current thread pointer, the need_reschedule +flag and the timeslice counter. + + +At present only the Multi-Level Queue (MLQ) scheduler is capable of +supporting SMP configurations. The main change made to this scheduler +is to cope with having several threads in execution at the same +time. Running threads are marked with the CPU that they are executing on. +When scheduling a thread, the scheduler skips past any running threads +until it finds a thread that is pending. While not a constant-time +algorithm, as in the single CPU case, this is still deterministic, +since the worst case time is bounded by the number of CPUs in the +system. + + +A second change to the scheduler is in the code used to decide when +the scheduler should be called to choose a new thread. The scheduler +attempts to keep the n CPUs running the +n highest priority threads. Since an event or +interrupt on one CPU may require a reschedule on another CPU, there +must be a mechanism for deciding this. The algorithm currently +implemented is very simple. Given a thread that has just been awakened +(or had its priority changed), the scheduler scans the CPUs, starting +with the one it is currently running on, for a current thread that is +of lower priority than the new one. If one is found then a reschedule +interrupt is sent to that CPU and the scan continues, but now using +the current thread of the rescheduled CPU as the candidate thread. In +this way the new thread gets to run as quickly as possible, hopefully +on the current CPU, and the remaining CPUs will pick up the remaining +highest priority threads as a consequence of processing the reschedule +interrupt. + + +The final change to the scheduler is in the handling of +timeslicing. Only one CPU receives timer interrupts, although all CPUs +must handle timeslicing. To make this work, the CPU that receives the +timer interrupt decrements the timeslice counter for all CPUs, not +just its own. If the counter for a CPU reaches zero, then it sends a +timeslice interrupt to that CPU. On receiving the interrupt the +destination CPU enters the scheduler and looks for another thread at +the same priority to run. This is somewhat more efficient than +distributing clock ticks to all CPUs, since the interrupt is only +needed when a timeslice occurs. + + +All existing synchronization mechanisms work as before in an SMP +system. Additional synchronization mechanisms have been added to +provide explicit synchronization for SMP, in the form of +spinlocks. + + + + + SMP Interrupt Handling + +The main area where the SMP nature of a system requires special +attention is in device drivers and especially interrupt handling. It +is quite possible for the ISR, DSR and thread components of a device +driver to execute on different CPUs. For this reason it is much more +important that SMP-capable device drivers use the interrupt-related +functions correctly. Typically a device driver would use the driver +API rather than call the kernel directly, but it is unlikely that +anybody would attempt to use a multiprocessor system without the +kernel package. + + +Two new functions have been added to the Kernel API +to do interrupt +routing: cyg_interrupt_set_cpu and +cyg_interrupt_get_cpu. Although not currently +supported, special values for the cpu argument may be used in future +to indicate that the interrupt is being routed dynamically or is +CPU-local. Once a vector has been routed to a new CPU, all other +interrupt masking and configuration operations are relative to that +CPU, where relevant. + + + +There are more details of how interrupts should be handled in SMP +systems in . + + + + + + + + + + + + + Thread creation + + + + cyg_thread_create + Create a new thread + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_thread_create + cyg_addrword_t sched_info + cyg_thread_entry_t* entry + cyg_addrword_t entry_data + char* name + void* stack_base + cyg_ucount32 stack_size + cyg_handle_t* handle + cyg_thread* thread + + + + + Description + +The cyg_thread_create function allows application +code and eCos packages to create new threads. In many applications +this only happens during system initialization and all required data +is allocated statically. However additional threads can be created at +any time, if necessary. A newly created thread is always in suspended +state and will not start running until it has been resumed via a call +to cyg_thread_resume. Also, if threads are +created during system initialization then they will not start running +until the eCos scheduler has been started. + + +The name argument is used +primarily for debugging purposes, making it easier to keep track of +which cyg_thread structure is associated with +which application-level thread. The kernel configuration option +CYGVAR_KERNEL_THREADS_NAME controls whether or not +this name is actually used. + + +On creation each thread is assigned a unique handle, and this will be +stored in the location pointed at by the handle argument. Subsequent operations on +this thread including the required +cyg_thread_resume should use this handle to +identify the thread. + + +The kernel requires a small amount of space for each thread, in the +form of a cyg_thread data structure, to hold +information such as the current state of that thread. To avoid any +need for dynamic memory allocation within the kernel this space has to +be provided by higher-level code, typically in the form of a static +variable. The thread argument +provides this space. + + + + Thread Entry Point + +The entry point for a thread takes the form: + + +void +thread_entry_function(cyg_addrword_t data) +{ + … +} + + +The second argument to cyg_thread_create is a +pointer to such a function. The third argument entry_data is used to pass additional +data to the function. Typically this takes the form of a pointer to +some static data, or a small integer, or 0 if the +thread does not require any additional data. + + +If the thread entry function ever returns then this is equivalent to +the thread calling cyg_thread_exit. Even though +the thread will no longer run again, it remains registered with the +scheduler. If the application needs to re-use the +cyg_thread data structure then a call to +cyg_thread_delete is required first. + + + + Thread Priorities + +The sched_info argument +provides additional information to the scheduler. The exact details +depend on the scheduler being used. For the bitmap and mlqueue +schedulers it is a small integer, typically in the range 0 to 31, with +0 being the highest priority. The lowest priority is normally used +only by the system's idle thread. The exact number of priorities is +controlled by the kernel configuration option +CYGNUM_KERNEL_SCHED_PRIORITIES. + + +It is the responsibility of the application developer to be aware of +the various threads in the system, including those created by eCos +packages, and to ensure that all threads run at suitable priorities. +For threads created by other packages the documentation provided by +those packages should indicate any requirements. + + +The functions cyg_thread_set_priority, +cyg_thread_get_priority, and +cyg_thread_get_current_priority can be used to +manipulate a thread's priority. + + + + Stacks and Stack Sizes + +Each thread needs its own stack for local variables and to keep track +of function calls and returns. Again it is expected that this stack is +provided by the calling code, usually in the form of static data, so +that the kernel does not need any dynamic memory allocation +facilities. cyg_thread_create takes two arguments +related to the stack, a pointer to the base of the stack and the total +size of this stack. On many processors stacks actually descend from the +top down, so the kernel will add the stack size to the base address to +determine the starting location. + + +The exact stack size requirements for any given thread depend on a +number of factors. The most important is of course the code that will +be executed in the context of this code: if this involves significant +nesting of function calls, recursion, or large local arrays, then the +stack size needs to be set to a suitably high value. There are some +architectural issues, for example the number of cpu registers and the +calling conventions will have some effect on stack usage. Also, +depending on the configuration, it is possible that some other code +such as interrupt handlers will occasionally run on the current +thread's stack. This depends in part on configuration options such as +CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK +and CYGSEM_HAL_COMMON_INTERRUPTS_ALLOW_NESTING. + + +Determining an application's actual stack size requirements is the +responsibility of the application developer, since the kernel cannot +know in advance what code a given thread will run. However, the system +does provide some hints about reasonable stack sizes in the form of +two constants: CYGNUM_HAL_STACK_SIZE_MINIMUM and +CYGNUM_HAL_STACK_SIZE_TYPICAL. These are defined by +the appropriate HAL package. The MINIMUM value is +appropriate for a thread that just runs a single function and makes +very simple system calls. Trying to create a thread with a smaller +stack than this is illegal. The TYPICAL value is +appropriate for applications where application calls are nested no +more than half a dozen or so levels, and there are no large arrays on +the stack. + + +If the stack sizes are not estimated correctly and a stack overflow +occurs, the probably result is some form of memory corruption. This +can be very hard to track down. The kernel does contain some code to +help detect stack overflows, controlled by the configuration option +CYGFUN_KERNEL_THREADS_STACK_CHECKING: a small +amount of space is reserved at the stack limit and filled with a +special signature: every time a thread context switch occurs this +signature is checked, and if invalid that is a good indication (but +not absolute proof) that a stack overflow has occurred. This form of +stack checking is enabled by default when the system is built with +debugging enabled. A related configuration option is +CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT: enabling +this option means that a thread can call the function +cyg_thread_measure_stack_usage to find out the +maximum stack usage to date. Note that this is not necessarily the +true maximum because, for example, it is possible that in the current +run no interrupt occurred at the worst possible moment. + + + + Valid contexts + +cyg_thread_create may be called during +initialization and from within thread context. It may not be called +from inside a DSR. + + + + Example + +A simple example of thread creation is shown below. This involves +creating five threads, one producer and four consumers or workers. The +threads are created in the system's +cyg_user_start: depending on the configuration it +might be more appropriate to do this elsewhere, for example inside +main. + + +#include <cyg/hal/hal_arch.h> +#include <cyg/kernel/kapi.h> + +// These numbers depend entirely on your application +#define NUMBER_OF_WORKERS 4 +#define PRODUCER_PRIORITY 10 +#define WORKER_PRIORITY 11 +#define PRODUCER_STACKSIZE CYGNUM_HAL_STACK_SIZE_TYPICAL +#define WORKER_STACKSIZE (CYGNUM_HAL_STACK_SIZE_MINIMUM + 1024) + +static unsigned char producer_stack[PRODUCER_STACKSIZE]; +static unsigned char worker_stacks[NUMBER_OF_WORKERS][WORKER_STACKSIZE]; +static cyg_handle_t producer_handle, worker_handles[NUMBER_OF_WORKERS]; +static cyg_thread_t producer_thread, worker_threads[NUMBER_OF_WORKERS]; + +static void +producer(cyg_addrword_t data) +{ + … +} + +static void +worker(cyg_addrword_t data) +{ + … +} + +void +cyg_user_start(void) +{ + int i; + + cyg_thread_create(PRODUCER_PRIORITY, &producer, 0, "producer", + producer_stack, PRODUCER_STACKSIZE, + &producer_handle, &producer_thread); + cyg_thread_resume(producer_handle); + for (i = 0; i < NUMBER_OF_WORKERS; i++) { + cyg_thread_create(WORKER_PRIORITY, &worker, i, "worker", + worker_stacks[i], WORKER_STACKSIZE, + &(worker_handles[i]), &(worker_threads[i])); + cyg_thread_resume(worker_handles[i]); + } +} + + + + + Thread Entry Points and C++ + +For code written in C++ the thread entry function must be either a +static member function of a class or an ordinary function outside any +class. It cannot be a normal member function of a class because such +member functions take an implicit additional argument +this, and the kernel has no way of knowing what +value to use for this argument. One way around this problem is to make +use of a special static member function, for example: + + +class fred { + public: + void thread_function(); + static void static_thread_aux(cyg_addrword_t); +}; + +void +fred::static_thread_aux(cyg_addrword_t objptr) +{ + fred* object = static_cast<fred*>(objptr); + object->thread_function(); +} + +static fred instance; + +extern "C" void +cyg_start( void ) +{ + … + cyg_thread_create( …, + &fred::static_thread_aux, + static_cast<cyg_addrword_t>(&instance), + …); + … +} + + +Effectively this uses the entry_data argument to +cyg_thread_create to hold the +this pointer. Unfortunately this approach does +require the use of some C++ casts, so some of the type safety that can +be achieved when programming in C++ is lost. + + + + + + + + + + + + Thread information + + + + cyg_thread_self + cyg_thread_idle_thread + cyg_thread_get_stack_base + cyg_thread_get_stack_size + cyg_thread_measure_stack_usage + Get basic thread information + + + + + +#include <cyg/kernel/kapi.h> + + + cyg_handle_t cyg_thread_self + + + + cyg_handle_t cyg_thread_idle_thread + + + + cyg_addrword_t cyg_thread_get_stack_base + cyg_handle_t thread + + + cyg_uint32 cyg_thread_get_stack_size + cyg_handle_t thread + + + cyg_uint32 cyg_thread_measure_stack_usage + cyg_handle_t thread + + + + + Description + +These functions can be used to obtain some basic information about +various threads in the system. Typically they serve little or no +purpose in real applications, but they can be useful during debugging. + + +cyg_thread_self returns a handle corresponding +to the current thread. It will be the same as the value filled in by +cyg_thread_create when the current thread was +created. This handle can then be passed to other functions such as +cyg_thread_get_priority. + + +cyg_thread_idle_thread returns the handle +corresponding to the idle thread. This thread is created automatically +by the kernel, so application-code has no other way of getting hold of +this information. + + +cyg_thread_get_stack_base and +cyg_thread_get_stack_size return information +about a specific thread's stack. The values returned will match the +values passed to cyg_thread_create when this +thread was created. + + +cyg_thread_measure_stack_usage is only available +if the configuration option +CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT is enabled. +The return value is the maximum number of bytes of stack space used so +far by the specified thread. Note that this should not be considered a +true upper bound, for example it is possible that in the current test +run the specified thread has not yet been interrupted at the deepest +point in the function call graph. Never the less the value returned +can give some useful indication of the thread's stack requirements. + + + + Valid contexts + +cyg_thread_self may only be called from thread +context. cyg_thread_idle_thread may be called +from thread or DSR context, but only after the system has been +initialized. cyg_thread_get_stack_base, +cyg_thread_get_stack_size and +cyg_thread_measure_stack_usage may be called +any time after the specified thread has been created, but measuring +stack usage involves looping over at least part of the thread's stack +so this should normally only be done from thread context. + + + + + + + + + + + Thread control + + + + cyg_thread_yield + cyg_thread_delay + cyg_thread_suspend + cyg_thread_resume + cyg_thread_release + Control whether or not a thread is running + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_thread_yield + + + + void cyg_thread_delay + cyg_tick_count_t delay + + + void cyg_thread_suspend + cyg_handle_t thread + + + void cyg_thread_resume + cyg_handle_t thread + + + void cyg_thread_release + cyg_handle_t thread + + + + + Description + +These functions provide some control over whether or not a particular +thread can run. Apart from the required use of +cyg_thread_resume to start a newly-created +thread, application code should normally use proper synchronization +primitives such as condition variables or mail boxes. + + + + Yield + +cyg_thread_yield allows a thread to relinquish +control of the processor to some other runnable thread which has the +same priority. This can have no effect on any higher-priority thread +since, if such a thread were runnable, the current thread would have +been preempted in its favour. Similarly it can have no effect on any +lower-priority thread because the current thread will always be run in +preference to those. As a consequence this function is only useful +in configurations with a scheduler that allows multiple threads to run +at the same priority, for example the mlqueue scheduler. If instead +the bitmap scheduler was being used then +cyg_thread_yield() would serve no purpose. + + +Even if a suitable scheduler such as the mlqueue scheduler has been +configured, cyg_thread_yield will still rarely +prove useful: instead timeslicing will be used to ensure that all +threads of a given priority get a fair slice of the available +processor time. However it is possible to disable timeslicing via the +configuration option CYGSEM_KERNEL_SCHED_TIMESLICE, +in which case cyg_thread_yield can be used to +implement a form of cooperative multitasking. + + + + Delay + +cyg_thread_delay allows a thread to suspend until +the specified number of clock ticks have occurred. For example, if a +value of 1 is used and the system clock runs at a frequency of 100Hz +then the thread will sleep for up to 10 milliseconds. This +functionality depends on the presence of a real-time system clock, as +controlled by the configuration option +CYGVAR_KERNEL_COUNTERS_CLOCK. + + +If the application requires delays measured in milliseconds or similar +units rather than in clock ticks, some calculations are needed to +convert between these units as described in . Usually these calculations can be done by +the application developer, or at compile-time. Performing such +calculations prior to every call to +cyg_thread_delay adds unnecessary overhead to the +system. + + + + Suspend and Resume + +Associated with each thread is a suspend counter. When a thread is +first created this counter is initialized to 1. +cyg_thread_suspend can be used to increment the +suspend counter, and cyg_thread_resume decrements +it. The scheduler will never run a thread with a non-zero suspend +counter. Therefore a newly created thread will not run until it has +been resumed. + + +An occasional problem with the use of suspend and resume functionality +is that a thread gets suspended more times than it is resumed and +hence never becomes runnable again. This can lead to very confusing +behaviour. To help with debugging such problems the kernel provides a +configuration option +CYGNUM_KERNEL_MAX_SUSPEND_COUNT_ASSERT which +imposes an upper bound on the number of suspend calls without matching +resumes, with a reasonable default value. This functionality depends +on infrastructure assertions being enabled. + + + + Releasing a Blocked Thread + +When a thread is blocked on a synchronization primitive such as a +semaphore or a mutex, or when it is waiting for an alarm to trigger, +it can be forcibly woken up using +cyg_thread_release. Typically this will call the +affected synchronization primitive to return false, indicating that +the operation was not completed successfully. This function has to be +used with great care, and in particular it should only be used on +threads that have been designed appropriately and check all return +codes. If instead it were to be used on, say, an arbitrary thread that +is attempting to claim a mutex then that thread might not bother to +check the result of the mutex lock operation - usually there would be +no reason to do so. Therefore the thread will now continue running in +the false belief that it has successfully claimed a mutex lock, and +the resulting behaviour is undefined. If the system has been built +with assertions enabled then it is possible that an assertion will +trigger when the thread tries to release the mutex it does not +actually own. + + +The main use of cyg_thread_release is in the +POSIX compatibility layer, where it is used in the implementation of +per-thread signals and cancellation handlers. + + + + Valid contexts + +cyg_thread_yield can only be called from thread +context, A DSR must always run to completion and cannot yield the +processor to some thread. cyg_thread_suspend, +cyg_thread_resume, and +cyg_thread_release may be called from thread or +DSR context. + + + + + + + + + + + + Thread termination + + + + cyg_thread_exit + cyg_thread_kill + cyg_thread_delete + Allow threads to terminate + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_thread_exit + + + + void cyg_thread_kill + cyg_handle_t thread + + + void cyg_thread_delete + cyg_handle_t thread + + + + + Description + +In many embedded systems the various threads are allocated statically, +created during initialization, and never need to terminate. This +avoids any need for dynamic memory allocation or other resource +management facilities. However if a given application does have a +requirement that some threads be created dynamically, must terminate, +and their resources such as the stack be reclaimed, then the kernel +provides the functions cyg_thread_exit, +cyg_thread_kill, and +cyg_thread_delete. + + +cyg_thread_exit allows a thread to terminate +itself, thus ensuring that it will not be run again by the scheduler. +However the cyg_thread data structure passed +to cyg_thread_create remains in use, and the +handle returned by cyg_thread_create remains +valid. This allows other threads to perform certain operations on the +terminated thread, for example to determine its stack usage via +cyg_thread_measure_stack_usage. When the handle +and cyg_thread structure are no longer +required, cyg_thread_delete should be called to +release these resources. If the stack was dynamically allocated then +this should not be freed until after the call to +cyg_thread_delete. + + +Alternatively, one thread may use cyg_thread_kill +on another This has much the same effect as the affected thread +calling cyg_thread_exit. However killing a thread +is generally rather dangerous because no attempt is made to unlock any +synchronization primitives currently owned by that thread or release +any other resources that thread may have claimed. Therefore use of +this function should be avoided, and +cyg_thread_exit is preferred. +cyg_thread_kill cannot be used by a thread to +kill itself. + + +cyg_thread_delete should be used on a thread +after it has exited and is no longer required. After this call the +thread handle is no longer valid, and both the +cyg_thread structure and the thread stack can +be re-used or freed. If cyg_thread_delete is +invoked on a thread that is still running then there is an implicit +call to cyg_thread_kill. + + + + Valid contexts + +cyg_thread_exit, +cyg_thread_kill and +cyg_thread_delete can only be called from thread +context. + + + + + + + + + + + + Thread priorities + + + + cyg_thread_get_priority + cyg_thread_get_current_priority + cyg_thread_set_priority + Examine and manipulate thread priorities + + + + +#include <cyg/kernel/kapi.h> + + + cyg_priority_t cyg_thread_get_priority + cyg_handle_t thread + + + cyg_priority_t cyg_thread_get_current_priority + cyg_handle_t thread + + + void cyg_thread_set_priority + cyg_handle_t thread + cyg_priority_t priority + + + + + Description + +Typical schedulers use the concept of a thread priority to determine +which thread should run next. Exactly what this priority consists of +will depend on the scheduler, but a typical implementation would be a +small integer in the range 0 to 31, with 0 being the highest priority. +Usually only the idle thread will run at the lowest priority. The +exact number of priority levels available depends on the +configuration, typically the option +CYGNUM_KERNEL_SCHED_PRIORITIES. + + +cyg_thread_get_priority can be used to determine +the priority of a thread, or more correctly the value last used in a +cyg_thread_set_priority call or when the thread +was first created. In some circumstances it is possible that the +thread is actually running at a higher priority. For example, if it +owns a mutex and priority ceilings or inheritance is being used to +prevent priority inversion problems, then the thread's priority may +have been boosted temporarily. +cyg_thread_get_current_priority returns the real +current priority. + + +In many applications appropriate thread priorities can be determined +and allocated statically. However, if it is necessary for a thread's +priority to change at run-time then the +cyg_thread_set_priority function provides this +functionality. + + + + Valid contexts + +cyg_thread_get_priority and +cyg_thread_get_current_priority can be called +from thread or DSR context, although the latter is rarely useful. +cyg_thread_set_priority should also only be +called from thread context. + + + + + + + + + + + Per-thread data + + + + cyg_thread_new_data_index + cyg_thread_free_data_index + cyg_thread_get_data + cyg_thread_get_data_ptr + cyg_thread_set_data + Manipulate per-thread data + + + + +#include <cyg/kernel/kapi.h> + + + cyg_ucount32 cyg_thread_new_data_index + + + + void cyg_thread_free_data_index + cyg_ucount32 index + + + cyg_addrword_t cyg_thread_get_data + cyg_ucount32 index + + + cyg_addrword_t* cyg_thread_get_data_ptr + cyg_ucount32 index + + + void cyg_thread_set_data + cyg_ucount32 index + cyg_addrword_t data + + + + + Description + +In some applications and libraries it is useful to have some data that +is specific to each thread. For example, many of the functions in the +POSIX compatibility package return -1 to indicate an error and store +additional information in what appears to be a global variable +errno. However, if multiple threads make concurrent +calls into the POSIX library and if errno were +really a global variable then a thread would have no way of knowing +whether the current errno value really corresponded +to the last POSIX call it made, or whether some other thread had run +in the meantime and made a different POSIX call which updated the +variable. To avoid such confusion errno is instead +implemented as a per-thread variable, and each thread has its own +instance. + + +The support for per-thread data can be disabled via the configuration +option CYGVAR_KERNEL_THREADS_DATA. If enabled, each +cyg_thread data structure holds a small array +of words. The size of this array is determined by the configuration +option CYGNUM_KERNEL_THREADS_DATA_MAX. When a +thread is created the array is filled with zeroes. + + +If an application needs to use per-thread data then it needs an index +into this array which has not yet been allocated to other code. This +index can be obtained by calling +cyg_thread_new_data_index, and then used in +subsequent calls to cyg_thread_get_data. +Typically indices are allocated during system initialization and +stored in static variables. If for some reason a slot in the array is +no longer required and can be re-used then it can be released by calling +cyg_thread_free_data_index, + + +The current per-thread data in a given slot can be obtained using +cyg_thread_get_data. This implicitly operates on +the current thread, and its single argument should be an index as +returned by cyg_thread_new_data_index. The +per-thread data can be updated using +cyg_thread_set_data. If a particular item of +per-thread data is needed repeatedly then +cyg_thread_get_data_ptr can be used to obtain the +address of the data, and indirecting through this pointer allows the +data to be examined and updated efficiently. + + +Some packages, for example the error and POSIX packages, have +pre-allocated slots in the array of per-thread data. These slots +should not normally be used by application code, and instead slots +should be allocated during initialization by a call to +cyg_thread_new_data_index. If it is known that, +for example, the configuration will never include the POSIX +compatibility package then application code may instead decide to +re-use the slot allocated to that package, +CYGNUM_KERNEL_THREADS_DATA_POSIX, but obviously +this does involve a risk of strange and subtle bugs if the +application's requirements ever change. + + + + Valid contexts + +Typically cyg_thread_new_data_index is only +called during initialization, but may also be called at any time in +thread context. cyg_thread_free_data_index, if +used at all, can also be called during initialization or from thread +context. cyg_thread_get_data, +cyg_thread_get_data_ptr, and +cyg_thread_set_data may only be called from +thread context because they implicitly operate on the current thread. + + + + + + + + + + + + Thread destructors + + + + cyg_thread_add_destructor + cyg_thread_rem_destructor + Call functions on thread termination + + + + +#include <cyg/kernel/kapi.h> +typedef void (*cyg_thread_destructor_fn)(cyg_addrword_t); + + + cyg_bool_t cyg_thread_add_destructor + cyg_thread_destructor_fn fn + cyg_addrword_t data + + + cyg_bool_t cyg_thread_rem_destructor + cyg_thread_destructor_fn fn + cyg_addrword_t data + + + + + Description + +These functions are provided for cases when an application requires a +function to be automatically called when a thread exits. This is often +useful when, for example, freeing up resources allocated by the thread. + + +This support must be enabled with the configuration option +CYGPKG_KERNEL_THREADS_DESTRUCTORS. When enabled, +you may register a function of type +cyg_thread_destructor_fn to be called on thread +termination using cyg_thread_add_destructor. You +may also provide it with a piece of arbitrary information in the +data argument which will be passed to the +destructor function fn when the thread +terminates. If you no longer wish to call a function previous +registered with cyg_thread_add_destructor, you +may call cyg_thread_rem_destructor with the same +parameters used to register the destructor function. Both these +functions return true on success and +false on failure. + + +By default, thread destructors are per-thread, which means that registering +a destructor function only registers that function for the current thread. +In other words, each thread has its own list of destructors. +Alternatively you may disable the configuration option +CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD in which +case any registered destructors will be run when any +threads exit. In other words, the thread destructor list is global and all +threads have the same destructors. + + +There is a limit to the number of destructors which may be registered, +which can be controlled with the +CYGNUM_KERNEL_THREADS_DESTRUCTORS configuration +option. Increasing this value will very slightly increase the amount +of memory in use, and when +CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD is +enabled, the amount of memory used per thread will increase. When the +limit has been reached, cyg_thread_add_destructor +will return false. + + + + Valid contexts + +When CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD +is enabled, these functions must only be called from a thread context +as they implicitly operate on the current thread. When +CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD is +disabled, these functions may be called from thread or DSR context, +or at initialization time. + + + + + + + + + + + + Exception handling + + + + cyg_exception_set_handler + cyg_exception_clear_handler + cyg_exception_call_handler + Handle processor exceptions + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_exception_set_handler + cyg_code_t exception_number + cyg_exception_handler_t* new_handler + cyg_addrword_t new_data + cyg_exception_handler_t** old_handler + cyg_addrword_t* old_data + + + void cyg_exception_clear_handler + cyg_code_t exception_number + + + void cyg_exception_call_handler + cyg_handle_t thread + cyg_code_t exception_number + cyg_addrword_t exception_info + + + + + Description + +Sometimes code attempts operations that are not legal on the current +hardware, for example dividing by zero, or accessing data through a +pointer that is not properly aligned. When this happens the hardware +will raise an exception. This is very similar to an interrupt, but +happens synchronously with code execution rather than asynchronously +and hence can be tied to the thread that is currently running. + + +The exceptions that can be raised depend very much on the hardware, +especially the processor. The corresponding documentation should be +consulted for more details. Alternatively the architectural HAL header +file hal_intr.h, or one of the +variant or platform header files it includes, will contain appropriate +definitions. The details of how to handle exceptions, including +whether or not it is possible to recover from them, also depend on the +hardware. + + +Exception handling is optional, and can be disabled through the +configuration option CYGPKG_KERNEL_EXCEPTIONS. If +an application has been exhaustively tested and is trusted never to +raise a hardware exception then this option can be disabled and code +and data sizes will be reduced somewhat. If exceptions are left +enabled then the system will provide default handlers for the various +exceptions, but these do nothing. Even the specific type of exception +is ignored, so there is no point in attempting to decode this and +distinguish between say a divide-by-zero and an unaligned access. +If the application installs its own handlers and wants details of the +specific exception being raised then the configuration option +CYGSEM_KERNEL_EXCEPTIONS_DECODE has to be enabled. + + +An alternative handler can be installed using +cyg_exception_set_handler. This requires a code +for the exception, a function pointer for the new exception handler, +and a parameter to be passed to this handler. Details of the +previously installed exception handler will be returned via the +remaining two arguments, allowing that handler to be reinstated, or +null pointers can be used if this information is of no interest. An +exception handling function should take the following form: + + +void +my_exception_handler(cyg_addrword_t data, cyg_code_t exception, cyg_addrword_t info) { - CYG_ISR_HANDLED = 1, /* Interrupt was handled */ - CYG_ISR_CALL_DSR = 2 /* Schedule DSR */ -}; -void cyg_interrupt_create( - cyg_vector_t vector, - cyg_priority_t priority, - cyg_addrword_t data, - cyg_ISR_t *isr, - cyg_DSR_t *dsr, - cyg_handle_t *handle, - cyg_interrupt *intr -) -Creates an interrupt object and returns a handle to it. The -object contains information about which interrupt vector to use -and the ISR and DSR that will be called after the interrupt object -is attached. The interrupt object will be allocated in the memory -passed in the intr parameter. The interrupt object is not immediately attached; -it must be attached with the cyg_interrupt_attach() call. -void cyg_interrupt_delete( - cyg_handle_t interrupt -) -Detaches the interrupt from the vector and frees the corresponding -memory. -void cyg_interrupt_attach( - cyg_handle_t interrupt -) -Attaches interrupt. -void cyg_interrupt_detach( - cyg_handle_t interrupt -) -Detaches interrupt. -void cyg_interrupt_get_vsr( - cyg_vector_t vector, - cyg_VSR_t **vsr -) -Returns a pointer to the VSR currently installed on vector -. -void cyg_interrupt_set_vsr( - cyg_vector_t vector, - cyg_VSR_t *vsr -) -Sets the current VSR on vector. A VSR directly attaches to -the hardware interrupt vector and needs to be written in assembler. -void cyg_interrupt_disable( void ) -Disables all interrupts. -void cyg_interrupt_enable( void ) -Enables all interrupts. -void cyg_interrupt_mask( - cyg_vector_t vector -) -Programs the interrupt controller to stop delivery of interrupts -on vector. On some architectures this will also disable all lower -priority interrupts while on others they remain enabled. -void cyg_interrupt_mask_intunsafe( - cyg_vector_t vector -) -Programs the interrupt controller to stop delivery of interrupts -on vector. On some architectures this will also disable all lower -priority interrupts while on others they remain enabled. -This version differs from cyg_drv_interrupt_unmask in not being interrupt -safe. -void cyg_interrupt_unmask( - cyg_vector_t vector -) -Programs the interrupt controller to allow delivery of interrupts -on the given interrupt vector. -void cyg_interrupt_unmask_intunsafe( - cyg_vector_t vector -) -Programs the interrupt controller to allow delivery of interrupts -on the given interrupt vector. -This version differs from cyg_drv_interrupt_unmask in not being interrupt -safe. -void cyg_interrupt_acknowledge( - cyg_vector_t vector -) -Should be used from inside an ISR to acknowledge receipt of -the interrupt. The interrupt must be acknowledged. If an interrupt -is not acknowledged, the interrupt may trigger immediately after -the ISR returns, causing the ISR to be called again in a loop. -void cyg_interrupt_configure( - cyg_vector_t vector, - cyg_bool_t level, - cyg_bool_t up ) -On some interrupt controllers the way an interrupt is detected -may be configured. The level parameter chooses between level- or -edge-triggered interrupts. The up parameter chooses between high -and low level for level triggered interrupts or rising and falling -edges for edge triggered interrupts. - - -<!-- <xref> -->Counters, clocks and alarms - -<!-- <index></index> -->Counters -The counter objects provided by the kernel provide an abstraction -of the clock facility that is generally provided. Application code -can associate alarms with counters, where an alarm is identified -by the number of ticks until it triggers, the action to be taken -on triggering, and whether or not the alarm should be repeated. -There are two different implementations of the counter objects. -The first stores all alarms in a single linked list. The alternative -implementation uses a table of linked lists, with the size of the -table being a separate configurable option. A single list is more -efficient in terms of memory usage and is generally adequate when -the application only makes use of a small number of alarms. For -more complicated operations it is better to have a table of lists -since this reduces the amount of computation whenever the timer -goes off. Assuming a table size of 8 (the default value) on average -the timer code will only need to check 1/8 of the pending -alarms instead of all of them. -The configuration options which select the counter implementation -are CYGIMP_KERNEL_COUNTERS_MULTI_LIST -(“Option: Implement counters using a table of lists”) -and CYGIMP_KERNEL_COUNTERS_SINGLE_LIST -(“Option: Implement counters using a single list”). -The following functions can be used to create and manipulate -counters: -void cyg_counter_create( - cyg_handle_t *counter, - cyg_counter *the_counter -) -Creates a new counter and places it in the space pointed to -by counter. A counter stores a value that is incremented by cyg_counter_tick(). -Alarms may be attached to counters, and the alarms will trigger -when the counter reaches a specified value. -void cyg_counter_delete( - cyg_handle_t counter -) -Deletes the given counter and frees the corresponding memory. -cyg_tick_count_t cyg_counter_current_value( - cyg_handle_t counter -) -Returns the current value of the given counter. -void cyg_counter_set_value( - cyg_handle_t counter, - cyg_tick_count_t new_value -) -Sets the counter's value to new_value. -void cyg_counter_tick( - cyg_handle_t counter -) -Advances the counter by one tick. -void cyg_counter_multi_tick( - cyg_handle_t counter - cyg_tick_count_t ticks -) -Advances the counter by multiple ticks. - - -Clocks -Clocks are counters which are associated with a stream - of ticks that represent time periods. Clocks have a - resolution associated with them, whereas counters do not. - -The most frequently used clock is the real-time -clock which serves two special purposes. First, it is -necessary to support clock and alarm related functions such as cyg_thread_delay(). -Second, it is needed to implement timeslicing in the mlqueue and -lottery schedulers. If the application does not require either of -these facilities, then it is possible to disable the real-time clock -support completely. It is also possible to disable just timeslicing -with the configuration option CYGSEM_KERNEL_SCHED_TIMESLICE, -or just the clock and alarm functions, using the option CYGFUN_KERNEL_THREADS_TIMER.. -The real-time clock is available if the configuration option CYGVAR_KERNEL_COUNTERS_CLOCK - is defined. -Clock resolution is stored in variables of type cyg_resolution_t -(). -void cyg_clock_create( - cyg_resolution_t resolution, - cyg_handle_t *handle, - cyg_clock *clock ) -Creates a clock object with the given resolution and places -it in the space pointed to by clock. A clock is a counter driven -by a regular source of ticks. For example the system real-time clock -is driven by a clock interrupt. -void cyg_clock_delete( cyg_handle_t clock ) -Deletes a clock object and frees the associated memory. -void cyg_clock_to_counter( -cyg_handle_t clock, - cyg_handle_t *counter -) -Converts a clock handle to a counter handle. The counter functions -can then be used with the counter handle. -void cyg_clock_set_resolution( - cyg_handle_t clock, - cyg_resolution_t resolution -) -Changes the resolution of a given clock object. -cyg_resolution_t cyg_clock_get_resolution( - cyg_handle_t clock ) -Returns the resolution of clock. -cyg_handle cyg_real_time_clock( void ) -Returns a handle to the system-supplied real-time clock. -cyg_tick_count_t cyg_current_time( void ) -Returns the real-time clock's counter. This is equivalent -to executing the code: - cyg_clock_to_counter(cyg_real_time_clock(), &h), - cyg_counter_current_value(h); - - -<!-- <index></index> -->Alarms -typedef void cyg_alarm_t(cyg_handle_t alarm, cyg_addrword_t data); -cyg_alarm_t is the type used for functions -which are used to handle alarm events. It is used in the function cyg_alarm_create(). -void cyg_alarm_create( - cyg_handle_t counter, - cyg_alarm_t *alarm_fn, - cyg_addrword_t data, - cyg_handle_t *handle, - cyg_alarm *alarm ) -Creates an alarm object. The alarm is attached to the counter - and is created in the memory pointed to by alarm -. When the alarm triggers, the handler function -alarmfn is called and is passed data -as a parameter. The alarm handler executes in the context of the -function that incremented the counter and thus triggered the alarm. - -If the alarm is associated with the real-time - clock, the alarm handler alarmfn - will be invoked by the - delayed service routine (DSR) that services the - real-time clock. This means that real-time clock alarm - handlers (which are possibly the most frequently used) - must follow the rules of behavior for DSRs. These rules - are outlined in . - -void cyg_alarm_delete( - cyg_handle_t alarm ) -Disables the alarm, detaches from the counter, invalidates -handles, and frees memory if it was dynamically allocated by cyg_alarm_create(). -void cyg_alarm_initialize( - cyg_handle_t alarm, - cyg_tick_count_t trigger, - cyg_tick_count_t interval -) -Initialize an alarm. This sets it to trigger at the tick with -value trigger. When an alarm triggers, this event is -dealt with by calling the alarmfn parameter which was -passed when the alarm was created using cyg_alarm_create(). -If interval is non-zero, then after the alarm has -triggered it will set itself to trigger again after interval - ticks. Otherwise, if interval is zero, the -alarm will be disabled automatically once it has triggered. -void cyg_alarm_get_times( - cyg_handle_t alarm, - cyg_tick_count_t *trigger, - cyg_tick_count_t *interval -) -Returns the trigger and interval parameters of the alarm. -void cyg_alarm_enable( - cyg_handle_t alarm ) -Enables an alarm that has been disabled by calling cyg_alarm_disable(). -void cyg_alarm_disable( - cyg_handle_t alarm ) -Disables an alarm. After an alarm is disabled it will not -be triggered unless it is subsequently re-enabled by calling cyg_alarm_enable() or -is reinitialized by calling cyg_alarm_initialize(). -Note, though, that if a periodic alarm that has been disabled -is re-enabled without reinitializing it will be in phase with the original sequence -of alarms. If it is reinitialized, the new -sequence of alarms will be in phase with the moment in which cyg_alarm_initialize() was -called. - - - -Synchronization - -Semaphores -The semaphores defined by the type cyg_sem_t -are counting semaphores. These objects are not referred to by handles, -but rather by the pointer to the variable in which the semaphore -is created. -void cyg_semaphore_init( - cyg_sem_t *sem, - cyg_ucount32 val ) -Initializes a semaphore. The initial semaphore count is set -to val. -void cyg_semaphore_destroy( - cyg_sem_t *sem -) -Destroys a semaphore. This must not be done while there are -any threads waiting on it. -void cyg_semaphore_wait( - cyg_sem_t *sem -) -If the semaphore count is zero, the current thread will wait -on the semaphore. If the count is non-zero, it will be decremented -and the thread will continue running. -cyg_bool_t cyg_semaphore_trywait( - cyg_sem_t *sem -) -A non-blocking version of cyg_semaphore_wait(). -This attempts to decrement the semaphore count. If the count is -positive, then the semaphore is decremented and true -is returned. If the count is zero then the semaphore remains unchanged, and -false is returned, but the current thread continues to -run. -cyg_bool_t cyg_semaphore_timed_wait( - cyg_sem_t *sem, - cyg_tick_count_t abstime -) -A time-out version of cyg_semaphore_wait(). -This attempts to decrement the semaphore count. If the count is -positive, then the semaphore is decremented and true is returned. -If the count is zero, it will wait for the semaphore to increment. -If however the abstime time-out is reached first, it will return -false without changing state, and the current thread will continue -to run. -The cyg_tick_count_t parameter -is an absolute time. If a relative time is required, you should -use cyg_current_time with -an offset. For example, to time out 200 ticks from the present you -would use: -cyg_semaphore_timed_wait(&sem, cyg_current_time() + 200); -cyg_semaphore_timed_wait() is -only available if the configuration option CYGFUN_KERNEL_THREADS_TIMER - is set. -void cyg_semaphore_post( - cyg_sem_t *sem -) -If there are threads waiting on this semaphore this will wake -exactly one of them. Otherwise it simply increments the semaphore -count. -void cyg_semaphore_peek( - cyg_sem_t *sem, - cyg_count32 *val ) -Returns the current semaphore count in the variable pointed -to by val. - - -<!-- <xref> -->Mutexes -Mutexes (mutual exclusion locks) are used in -a similar way to semaphores. A mutex only has two states, locked -and unlocked. Mutexes are used to protect accesses to shared data -or resources. When a thread locks a mutex it becomes the owner. -Only the mutex's owner may unlock it. While a mutex remains -locked, the owner should not lock it again, as the behavior is undefined -and probably dangerous. -If non-owners try to lock the mutex, they will be suspended -until the mutex is available again, at which point they will own -the mutex. -void cyg_mutex_init( - cyg_mutex_t *mutex -) -Initializes a mutex. It is initialized in the unlocked state. -void cyg_mutex_destroy( - cyg_mutex_t *mutex -) -Destroys a mutex. A mutex should not be destroyed in the locked -state, as the behavior is undefined. -cyg_bool_t cyg_mutex_lock( - cyg_mutex_t *mutex -) -Changes the nutex from the unlocked state to the locked state. -When this happens the mutex becomes owned by the current thread. -If the mutex is locked, the current thread will wait until the mutex -becomes unlocked before performing this operation. The result of -this function will be TRUE if the mutex has been locked, or FALSE -if it has not. A FALSE result can result if the thread has been -released from its wait by a call to cyg_thread_release() or cyg_mutex_release(). -void cyg_mutex_unlock( - cyg_mutex_t *mutex -) -Changes the mutex from the locked state to the unlocked state. -This function may only be called by the thread which locked the -mutex, and should not be called on an unlocked mutex. -void cyg_mutex_release( - cyg_mutex_t *mutex -) -Release all threads waiting on the mutex pointed to by the -mutex argument. These threads will return from cyg_mutex_lock() -with a FALSE result and will not have claimed the mutex. This function -has no effect on any thread that may have the mutex claimed. -void cyg_mutex_set_protocol( - cyg_mutex_t *mutex, - enum cyg_mutex_protocol protocol) -As described in the Thread Synchronization section, eCos's -mutex can use a number of schemes when dealing with priority inversion. -This function is used to set the protocol for the mutex. protocol - may take one of 3 values: CYG_MUTEX_NONE, CYG_MUTEX_INHERIT, -CYG_MUTEX_CEILING. The first indicates no inversion -protocol will be used. The second uses the SIMPLE inversion protocol, -and the last uses the ceiling protocol. -void cyg_mutex_set_ceiling( - cyg_mutex_t *mutex, - cyg_priority_t priority) -When using the ceiling inversion protocol, this function allows -the ceiling thread priority of an obtained mutex to be set. -cyg_priority_t cyg_thread_get_current_priority( - cyg_handle_t thread) -Returns the current thread priority. If the thread is running -at a higher priority than normal due to priority inversion, this -functions returns the inverted priority, whereas -cyg_thread_get_priority() returns -the normal priority. - - -<!-- <xref> -->Condition Variables -Condition variables are a synchronization mechanism -which (used with a mutex) grants several threads mutually exclusive -access to shared data and to broadcast availability of that data -to all the other threads. -A typical example of the use of condition variables is when -one thread (the producer) is producing data and several other (consumer) -threads are waiting for that data to be ready. The consumers will -wait by invoking cyg_cond_wait(). -The producer will lock access to the data with a mutex, and when -it has generated enough data for the other processes to consume, -it will invoke cyg_cond_broadcast() to -wake up the consumers. The Getting Started with eCos book -has example programs which use condition variables to implement -a simple message passing system between threads. -void cyg_cond_init( - cyg_cond_t *cond, - cyg_mutex_t *mutex -) -Initializes the condition variable. A condition variable is -attached to a specific mutex. -void cyg_cond_destroy( - cyg_cond_t *cond -) -Destroys the condition variable cond. This must not be done -on a condition variable which is in use. After it has been destroyed, -it may be subsequently reinitialized. -void cyg_cond_wait( - cyg_cond_t *cond -) -Causes the current thread to wait on the condition variable, -while simultaneously unlocking the corresponding mutex. cyg_cond_wait() may -be called by a thread which has the corresponding mutex locked. -The thread can only be awakened by a call to cyg_cond_signal() or cyg_cond_broadcast() on -the same condition variable. When the thread is awakened, the mutex -will be reclaimed before this function proceeds. Since it may have -to wait for this, cyg_cond_wait() should -only be used in a loop since the condition may become false in the meantime. -This is shown in the following example: -extern cyg_mutex_t mutex; -extern cyg_cond_t cond; - -cyg_mutex_lock( &mutex ); -... - -while( condition_not_true ) + … +} + + +The data argument corresponds to the new_data +parameter supplied to cyg_exception_set_handler. +The exception code is provided as well, in case a single handler is +expected to support multiple exceptions. The info +argument will depend on the hardware and on the specific exception. + + +cyg_exception_clear_handler can be used to +restore the default handler, if desired. It is also possible for +software to raise an exception and cause the current handler to be +invoked, but generally this is useful only for testing. + + +By default the system maintains a single set of global exception +handlers. However, since exceptions occur synchronously it is +sometimes useful to handle them on a per-thread basis, and have a +different set of handlers for each thread. This behaviour can be +obtained by disabling the configuration option +CYGSEM_KERNEL_EXCEPTIONS_GLOBAL. If per-thread +exception handlers are being used then +cyg_exception_set_handler and +cyg_exception_clear_handler apply to the current +thread. Otherwise they apply to the global set of handlers. + + + +In the current implementation +cyg_exception_call_handler can only be used on +the current thread. There is no support for delivering an exception to +another thread. + + +Exceptions at the eCos kernel level refer specifically to +hardware-related events such as unaligned accesses to memory or +division by zero. There is no relation with other concepts that are +also known as exceptions, for example the throw and +catch facilities associated with C++. + + + + + Valid contexts + +If the system is configured with a single set of global exception +handlers then +cyg_exception_set_handler and +cyg_exception_clear_handler may be called during +initialization or from thread context. If instead per-thread exception +handlers are being used then it is not possible to install new +handlers during initialization because the functions operate +implicitly on the current thread, so they can only be called from +thread context. cyg_exception_call_handler should +only be called from thread context. + + + + + + + + + + + + Counters + + + + cyg_counter_create + cyg_counter_delete + cyg_counter_current_value + cyg_counter_set_value + cyg_counter_tick + Count event occurrences + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_counter_create + cyg_handle_t* handle + cyg_counter* counter + + + void cyg_counter_delete + cyg_handle_t counter + + + cyg_tick_count_t cyg_counter_current_value + cyg_handle_t counter + + + void cyg_counter_set_value + cyg_handle_t counter + cyg_tick_count_t new_value + + + void cyg_counter_tick + cyg_handle_t counter + + + + + Description + +Kernel counters can be used to keep track of how many times a +particular event has occurred. Usually this event is an external +signal of some sort. The most common use of counters is in the +implementation of clocks, but they can be useful with other event +sources as well. Application code can attach alarms to counters, causing a function +to be called when some number of events have occurred. + + +A new counter is initialized by a call to +cyg_counter_create. The first argument is used to +return a handle to the new counter which can be used for subsequent +operations. The second argument allows the application to provide the +memory needed for the object, thus eliminating any need for dynamic +memory allocation within the kernel. If a counter is no longer +required and does not have any alarms attached then +cyg_counter_delete can be used to release the +resources, allowing the cyg_counter data +structure to be re-used. + + +Initializing a counter does not automatically attach it to any source +of events. Instead some other code needs to call +cyg_counter_tick whenever a suitable event +occurs, which will cause the counter to be incremented and may cause +alarms to trigger. The current value associated with the counter can +be retrieved using cyg_counter_current_value and +modified with cyg_counter_set_value. Typically +the latter function is only used during initialization, for example to +set a clock to wallclock time, but it can be used to reset a counter +if necessary. However cyg_counter_set_value will +never trigger any alarms. A newly initialized counter has a starting +value of 0. + + +The kernel provides two different implementations of counters. The +default is CYGIMP_KERNEL_COUNTERS_SINGLE_LIST which +stores all alarms attached to the counter on a single list. This is +simple and usually efficient. However when a tick occurs the kernel +code has to traverse this list, typically at DSR level, so if there +are a significant number of alarms attached to a single counter this +will affect the system's dispatch latency. The alternative +implementation, CYGIMP_KERNEL_COUNTERS_MULTI_LIST, +stores each alarm in one of an array of lists such that at most one of +the lists needs to be searched per clock tick. This involves extra +code and data, but can improve real-time responsiveness in some +circumstances. Another configuration option that is relevant here +is CYGIMP_KERNEL_COUNTERS_SORT_LIST, which is +disabled by default. This provides a trade off between doing work +whenever a new alarm is added to a counter and doing work whenever a +tick occurs. It is application-dependent which of these is more +appropriate. + + + + Valid contexts + +cyg_counter_create is typically called during +system initialization but may also be called in thread context. +Similarly cyg_counter_delete may be called during +initialization or in thread context. +cyg_counter_current_value, +cyg_counter_set_value and +cyg_counter_tick may be called during +initialization or from thread or DSR context. In fact, +cyg_counter_tick is usually called from inside a +DSR in response to an external event of some sort. + + + + + + + + + + + + Clocks + + + + cyg_clock_create + cyg_clock_delete + cyg_clock_to_counter + cyg_clock_set_resolution + cyg_clock_get_resolution + cyg_real_time_clock + cyg_current_time + Provide system clocks + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_clock_create + cyg_resolution_t resolution + cyg_handle_t* handle + cyg_clock* clock + + + void cyg_clock_delete + cyg_handle_t clock + + + void cyg_clock_to_counter + cyg_handle_t clock + cyg_handle_t* counter + + + void cyg_clock_set_resolution + cyg_handle_t clock + cyg_resolution_t resolution + + + cyg_resolution_t cyg_clock_get_resolution + cyg_handle_t clock + + + cyg_handle_t cyg_real_time_clock + + + + cyg_tick_count_t cyg_current_time + + + + + + Description + +In the eCos kernel clock objects are a special form of counter objects. They are attached to +a specific type of hardware, clocks that generate ticks at very +specific time intervals, whereas counters can be used with any event +source. + + +In a default configuration the kernel provides a single clock +instance, the real-time clock. This gets used for timeslicing and for +operations that involve a timeout, for example +cyg_semaphore_timed_wait. If this functionality +is not required it can be removed from the system using the +configuration option CYGVAR_KERNEL_COUNTERS_CLOCK. +Otherwise the real-time clock can be accessed by a call to +cyg_real_time_clock, allowing applications to +attach alarms, and the current counter value can be obtained using +cyg_current_time. + + +Applications can create and destroy additional clocks if desired, +using cyg_clock_create and +cyg_clock_delete. The first argument to +cyg_clock_create specifies the +resolution this clock +will run at. The second argument is used to return a handle for this +clock object, and the third argument provides the kernel with the +memory needed to hold this object. This clock will not actually tick +by itself. Instead it is the responsibility of application code to +initialize a suitable hardware timer to generate interrupts at the +appropriate frequency, install an interrupt handler for this, and +call cyg_counter_tick from inside the DSR. +Associated with each clock is a kernel counter, a handle for which can +be obtained using cyg_clock_to_counter. + + + + Clock Resolutions and Ticks + +At the kernel level all clock-related operations including delays, +timeouts and alarms work in units of clock ticks, rather than in units +of seconds or milliseconds. If the calling code, whether the +application or some other package, needs to operate using units such +as milliseconds then it has to convert from these units to clock +ticks. + + +The main reason for this is that it accurately reflects the +hardware: calling something like nanosleep with a +delay of ten nanoseconds will not work as intended on any real +hardware because timer interrupts simply will not happen that +frequently; instead calling cyg_thread_delay with +the equivalent delay of 0 ticks gives a much clearer indication that +the application is attempting something inappropriate for the target +hardware. Similarly, passing a delay of five ticks to +cyg_thread_delay makes it fairly obvious that +the current thread will be suspended for somewhere between four and +five clock periods, as opposed to passing 50000000 to +nanosleep which suggests a granularity that is +not actually provided. + + +A secondary reason is that conversion between clock ticks and units +such as milliseconds can be somewhat expensive, and whenever possible +should be done at compile-time or by the application developer rather +than at run-time. This saves code size and cpu cycles. + + +The information needed to perform these conversions is the clock +resolution. This is a structure with two fields, a dividend and a +divisor, and specifies the number of nanoseconds between clock ticks. +For example a clock that runs at 100Hz will have 10 milliseconds +between clock ticks, or 10000000 nanoseconds. The ratio between the +resolution's dividend and divisor will therefore be 10000000 to 1, and +typical values for these might be 1000000000 and 100. If the clock +runs at a different frequency, say 60Hz, the numbers could be +1000000000 and 60 respectively. Given a delay in nanoseconds, this can +be converted to clock ticks by multiplying with the the divisor and +then dividing by the dividend. For example a delay of 50 milliseconds +corresponds to 50000000 nanoseconds, and with a clock frequency of +100Hz this can be converted to +((50000000 * 100) / 1000000000) = 5 +clock ticks. Given the large numbers involved this arithmetic normally +has to be done using 64-bit precision and the +long long data type, but allows code to run on +hardware with unusual clock frequencies. + + +The default frequency for the real-time clock on any platform is +usually about 100Hz, but platform-specific documentation should be +consulted for this information. Usually it is possible to override +this default by configuration options, but again this depends on the +capabilities of the underlying hardware. The resolution for any clock +can be obtained using cyg_clock_get_resolution. +For clocks created by application code, there is also a function +cyg_clock_set_resolution. This does not affect +the underlying hardware timer in any way, it merely updates the +information that will be returned in subsequent calls to +cyg_clock_get_resolution: changing the actual +underlying clock frequency will require appropriate manipulation of +the timer hardware. + + + + Valid contexts + +cyg_clock_create is usually only called during +system initialization (if at all), but may also be called from thread +context. The same applies to cyg_clock_delete. +The remaining functions may be called during initialization, from +thread context, or from DSR context, although it should be noted that +there is no locking between +cyg_clock_get_resolution and +cyg_clock_set_resolution so theoretically it is +possible that the former returns an inconsistent data structure. + + + + + + + + + + + + Alarms + + + + cyg_alarm_create + cyg_alarm_delete + cyg_alarm_initialize + cyg_alarm_enable + cyg_alarm_disable + Run an alarm function when a number of events have occurred + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_alarm_create + cyg_handle_t counter + cyg_alarm_t* alarmfn + cyg_addrword_t data + cyg_handle_t* handle + cyg_alarm* alarm + + + void cyg_alarm_delete + cyg_handle_t alarm + + + void cyg_alarm_initialize + cyg_handle_t alarm + cyg_tick_count_t trigger + cyg_tick_count_t interval + + + void cyg_alarm_enable + cyg_handle_t alarm + + + void cyg_alarm_disable + cyg_handle_t alarm + + + + + Description + +Kernel alarms are used together with counters and allow for action to +be taken when a certain number of events have occurred. If the counter +is associated with a clock then the alarm action happens when the +appropriate number of clock ticks have occurred, in other words after +a certain period of time. + + +Setting up an alarm involves a two-step process. First the alarm must +be created with a call to cyg_alarm_create. This +takes five arguments. The first identifies the counter to which the +alarm should be attached. If the alarm should be attached to the +system's real-time clock then cyg_real_time_clock +and cyg_clock_to_counter can be used to get hold +of the appropriate handle. The next two arguments specify the action +to be taken when the alarm is triggered, in the form of a function +pointer and some data. This function should take the form: + + +void +alarm_handler(cyg_handle_t alarm, cyg_addrword_t data) { - cyg_cond_wait( &cond ); + … } - -... - -cyg_mutex_unlock( &mutex ); + + +The data argument passed to the alarm function corresponds to the +third argument passed to cyg_alarm_create. +The fourth argument to cyg_alarm_create is used +to return a handle to the newly-created alarm object, and the final +argument provides the memory needed for the alarm object and thus +avoids any need for dynamic memory allocation within the kernel. + + +Once an alarm has been created a further call to +cyg_alarm_initialize is needed to activate it. +The first argument specifies the alarm. The second argument indicates +the number of events, for example clock ticks, that need to occur +before the alarm triggers. If the third argument is 0 then the alarm +will only trigger once. A non-zero value specifies that the alarm +should trigger repeatedly, with an interval of the specified number of +events. + + +Alarms can be temporarily disabled and reenabled using +cyg_alarm_disable and +cyg_alarm_enable. Alternatively another call to +cyg_alarm_initialize can be used to modify the +behaviour of an existing alarm. If an alarm is no longer required then +the associated resources can be released using +cyg_alarm_delete. + + +The alarm function is invoked when a counter tick occurs, in other +words when there is a call to cyg_counter_tick, +and will happen in the same context. If the alarm is associated with +the system's real-time clock then this will be DSR context, following +a clock interrupt. If the alarm is associated with some other +application-specific counter then the details will depend on how that +counter is updated. + + + + Valid contexts + +cyg_alarm_create +cyg_alarm_initialize is typically called during +system initialization but may also be called in thread context. The +same applies to cyg_alarm_delete. +cyg_alarm_initialize, +cyg_alarm_disable and +cyg_alarm_enable may be called during +initialization or from thread or DSR context, but +cyg_alarm_enable and +cyg_alarm_initialize may be expensive operations +and should only be called when necessary. + + + + + + + + + + + + Mutexes + + + + cyg_mutex_init + cyg_mutex_destroy + cyg_mutex_lock + cyg_mutex_trylock + cyg_mutex_unlock + cyg_mutex_release + cyg_mutex_set_ceiling + cyg_mutex_set_protocol + Synchronization primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_mutex_init + cyg_mutex_t* mutex + + + void cyg_mutex_destroy + cyg_mutex_t* mutex + + + cyg_bool_t cyg_mutex_lock + cyg_mutex_t* mutex + + + cyg_bool_t cyg_mutex_trylock + cyg_mutex_t* mutex + + + void cyg_mutex_unlock + cyg_mutex_t* mutex + + + void cyg_mutex_release + cyg_mutex_t* mutex + + + void cyg_mutex_set_ceiling + cyg_mutex_t* mutex + cyg_priority_t priority + + + void cyg_mutex_set_protocol + cyg_mutex_t* mutex + enum cyg_mutex_protocol protocol/ + + + + + Description + +The purpose of mutexes is to let threads share resources safely. If +two or more threads attempt to manipulate a data structure with no +locking between them then the system may run for quite some time +without apparent problems, but sooner or later the data structure will +become inconsistent and the application will start behaving strangely +and is quite likely to crash. The same can apply even when +manipulating a single variable or some other resource. For example, +consider: + + +static volatile int counter = 0; + +void +process_event(void) +{ + … + + counter++; +} - - cyg_bool_t cyg_cond_timed_wait( - cyg_cond_t *cond, - cyg_tick_count_t abstime -) -A time-out version of cyg_cond_wait() which -waits for a signal or broadcast. If a signal or broadcast is received -it returns true, but if one is not received by -abstime, it returns false. -The cyg_tick_count_t parameter -is an absolute time. If a relative time is required, you should -use cyg_current_time with -an offset. For example, to time out 200 ticks from the present you -would use: -cyg_cond_timed_wait(&sem, cyg_current_time() + 200); -cyg_cond_timed_wait() is -only available if the configuration option CYGMFN_KERNEL_SYNCH_CONDVAR_TIMED_WAIT - is set. -void cyg_cond_signal( - cyg_cond_t *cond -) -Wakes up at least one thread which is waiting on the condition -variable. When a thread is awakened it will become the owner of -the mutex. cyg_cond_signal() may -be called by the thread which currently owns the mutex to which -the condition variable is attached. -void cyg_cond_broadcast( - cyg_cond_t *cond -) -Wakes all the threads waiting on the -condition variable. Each time a thread is awakened it will become -the current owner of the mutex. - - - -<!-- <xref> -->Memory pools -There are two sorts of memory pools. A variable -size memory pool is for allocating blocks of any size. A fixed size -memory pool, has the block size specified when the pool is created -and only provides blocks of that size. -Blocking, non-blocking and “blocking with time-out” versions -of these calls are provided. -void cyg_mempool_var_create( - void *base, - cyg_int32 size, - cyg_handle_t *handle, - cyg_mempool_var *var -) -Creates a variable size memory pool. The parameters are: - - -base - - -base of memory to use for pool - - - -size - - -size of memory pool in bytes - - - -handle - - -returned handle of memory pool - - - -var - - -space to put pool structure in - - - -void cyg_mempool_var_delete( - cyg_handle_t varpool -) -Deletes the variable size memory pool varpool. - -void *cyg_mempool_var_alloc( - cyg_handle_t varpool, - cyg_int32 size ) -Allocates a block of length size. This will -block until the memory becomes available. -void *cyg_mempool_var_timed_alloc( - cyg_handle_t varpool, - cyg_int32 size, - cyg_tick_count_t abstime -) -Allocates a block of length size. If the requested -amount of memory is not available, it will wait until abstime - before giving up and returning NULL. -void *cyg_mempool_var_try_alloc( - cyg_handle_t varpool, - cyg_int32 size ) -Allocates a block of length size. -NULL is returned if not enough is available. -void cyg_mempool_var_free( - cyg_handle_t varpool, - void *p ) -Frees memory back into variable size pool varpool. - -cyg_bool_t cyg_mempool_var_waiting( - cyg_handle_t varpool -) -Returns true if any threads are waiting for memory in -varpool. -typedef struct { - cyg_int32 totalmem; - cyg_int32 freemem; - void *base; - cyg_int32 size; - cyg_int32 blocksize; - cyg_int32 maxfree; // The largest free block -} cyg_mempool_info; - - void cyg_mempool_var_get_info( - cyg_handle_t varpool, - cyg_mempool_info *info -) -Puts information about a variable memory pool into the structure -provided. -void cyg_mempool_fix_create( - void *base, - cyg_int32 size, - cyg_int32 blocksize, - cyg_handle_t *handle, - cyg_mempool_fix *fix -) -Create a fixed size memory pool. This function takes the following -parameters: - - -base - - -base of memory to use for pool - - - -size - - -size of total space requested - - - -blocksize - - -size of individual elements - - - -handle - - -returned handle of memory pool - - - -fix - - -space to put pool structure in - - - -void cyg_mempool_fix_delete( - cyg_handle_t fixpool -) -Deletes the given fixed size memory pool. -void *cyg_mempool_fix_alloc( - cyg_handle_t fixpool -) -Allocates a block. If the memory is not available immediately, -this blocks until the memory becomes available. -void *cyg_mempool_fix_timed_alloc( - cyg_handle_t fixpool, - cyg_tick_count_t abstime -) -Allocates a block. If the memory is not already available, -it will try until abstime before giving up and -returning a NULL. -void *cyg_mempool_fix_try_alloc( - cyg_handle_t fixpool -) -Allocates a block. NULL is returned if no memory is available. -void cyg_mempool_fix_free( - cyg_handle_t fixpool, - void *p ) -Frees memory back into fixed size pool. -cyg_bool_t cyg_mempool_fix_waiting( - cyg_handle_t fixpool -) -Returns true if there are any threads waiting for memory in -the given memory pool. -void cyg_mempool_fix_get_info( - cyg_handle_t fixpool, - cyg_mempool_info *info -) -Puts information about a variable memory pool into the structure -provided. -The fixed size memory pool simply returns blocks of memory -of exactly the blocksize requested. If the pool is being used to -allocate memory for a type that has alignment constraints (such -as 4-byte alignment), then it is up to the user to align the memory -appropriately for the type in question. Alternatively, choose a blocksize -that is an exact multiple of the required alignment. -The memory available from the memory pools will not be the -same size as the memory supplied to it. Some of the memory is used -for internal data structures of the allocator. cyg_mempool_fix_get_info() and cyg_mempool_var_get_info() may -be used to determine the available memory. - - -<!-- <index></index> -->Message boxes -Message boxes are a primitive mechanism for exchanging messages -between threads, inspired by the µITRON -specification. A message box can be created with cyg_mbox_create() before -the scheduler is started, and two threads in a typical producer/consumer relationship -can access it. One thread, the producer, will use cyg_mbox_put() to -make data available to the consumer thread which uses cyg_mbox_get() to -access the data. -The size of the internal message queue is configured by the -“Message box queue size” ( CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE ) -configuration option. The default value is 10. -Blocking, non-blocking and “blocking with time-out” versions -of these calls are provided. -void cyg_mbox_create( - cyg_handle_t *handle, - cyg_mbox *mbox ) -Creates a message box using the space provided in the mbox -parameter, and returns a handle for future access to that message -box. -void cyg_mbox_delete( - cyg_handle_t mbox ) -Deletes the given message box. -void *cyg_mbox_get( - cyg_handle_t mbox ) -Waits for a message to be available, then retrieves it and -returns the address of the data. -void *cyg_mbox_timed_get( - cyg_handle_t mbox, - cyg_tick_count_t timeout -) -Waits for a message to be available, but times out if timeout -time passes. This version of the function is only available if the -configuration option CYGFUN_KERNEL_THREADS_TIMER -is turned on. -void *cyg_mbox_tryget( - cyg_handle_t mbox ) -Checks to see if a message is ready. If no message is available -it returns immediately with a return value of NULL. -If a message is available it retrieves it and returns the address of the data. - -void *cyg_mbox_peek_item( - cyg_handle_t mbox ) -Checks to see if a message is ready, and if one is available -returns the address of the data without removing -the message from the queue. If no message is available it returns -NULL. -cyg_bool_t cyg_mbox_put( - cyg_handle_t mbox, - void *item ) -Places a message in the given message box. If the queue is -full it will block until the message can be sent. It returns true -if the message was successfully sent, and false -if the message was not sent and its sleep was awakened by the kernel before -the message could be sent. -The cyg_mbox_put() function -is only available if the CYGMTH_MBOXT_PUT_CAN_WAIT configuration -has been selected. -cyg_bool_t cyg_mbox_timed_put( - cyg_handle_t mbox, - void *item, - cyg_tick_count_t abstime -) -A time-out version of cyg_mbox_put(). -This will try to place the message in the given message box. If -the queue is full, it will wait until abstime before -giving up and returning false. -The cyg_mbox_timed_put() function -is only available if the both the CYGMFN_KERNEL_SYNCH_MBOXT_PUT_CAN_WAIT -and CYGFUN_KERNEL_THREADS_TIMER configuration -have been selected. -cyg_bool_t cyg_mbox_tryput( - cyg_handle_t mbox, - void *item ) -Tries to place a message in the given message box. It returns -true if the message was successfully sent, and -false if the message -could not be sent immediately, usually because the queue was full. -cyg_count32 cyg_mbox_peek( - cyg_handle_t mbox ) -Takes a peek at the queue and returns the number of messages -waiting in it. -cyg_bool_t cyg_mbox_waiting_to_get( - cyg_handle_t mbox ) -Queries the kernel to see if other processes are waiting to -receive a message in the given message box. Returns true -if other processes are waiting, false otherwise. -cyg_bool_t cyg_mbox_waiting_to_put( - cyg_handle_t mbox ) -Queries the kernel to see if other processes -are waiting to send a message in the given message box. Returns -true if other processes are waiting, false - otherwise. - - -Flags -Flags are a synchronization mechanism which -allow a thread to wait for a single condition or a combination of -conditions. The conditions are represented by bits in a 32 bit word. Flags -are inspired by the µITRON specification. -Flags are of type cyg_flag_t, which are -32 bit words, and routines are provided to set or mask some bits -in the flag value. -A “consumer side” thread can wait for a “producer -side” thread to set the entire collection of bits, or any -subset of them. -When a thread sets some bits in a flag, all threads whose -requirements are now satisfied are woken up; thus flags have broadcast -semantics. A variation on the wait call can specify that the flag -value be cleared when the wait call is satisfied, in which case -the setting of bits would not be a broadcast. -Blocking, non-blocking, and “blocking with time-out” versions -of the wait calls are provided. -void cyg_flag_init( - cyg_flag_t *flag -) -Initializes a flag variable. -void cyg_flag_destroy( - cyg_flag_t *flag -) -Destroys a flag variable. -void cyg_flag_setbits( - cyg_flag_t *flag, - cyg_flag_value_t value -) -Sets the bits in flag which are set in -value. -A side effect of cyg_flag_setbits() is -that the kernel wakes up any waiting threads whose requirements -are now satisfied. - - -flag - - -A pointer to the flag whose bits are being set. The new setting -of flag will be -*flag -> (*flag | value). - - - -value - - -A word whose 1 bits will also be set in - *flag. - - - -void cyg_flag_maskbits( -cyg_flag_t *flag, -cyg_flag_value_t value -) - -Clear the bits in the given flag which are zero -in the value. This cannot result in new threads being -eligible for awakening. - - -flag - - -A pointer to the flag whose bits are being cleared. The new -setting of flag will be -*flag -> (*flag & value). - - - -value - - -A word whose 0 bits will also be cleared in - *flag. - - - -We now describe the cyg_flag_wait(), -which frequently uses the following macros: - #define CYG_FLAG_WAITMODE_AND ((cyg_flag_mode_t)0) - #define CYG_FLAG_WAITMODE_OR ((cyg_flag_mode_t)2) - #define CYG_FLAG_WAITMODE_CLR ((cyg_flag_mode_t)1) - - - cyg_flag_value_t cyg_flag_wait( - cyg_flag_t *flag, - cyg_flag_value_t pattern, - cyg_flag_mode_t mode -) -Wait for all the bits which are one in pattern to -be set in the flag value (if mode -is CYG_FLAG_WAITMODE_AND) -or for any of the bits which are one in pattern to be -set in the flag value (if mode is -CYG_FLAG_WAITMODE_OR). -When cyg_flag_wait() returns, -meaning that the condition is met, the flag value which succeeded -is returned from the call; in other circumstances (such as a bad -value for mode or pattern), zero -is returned to indicate the error. -If the mode is one of those above plus CYG_FLAG_WAITMODE_CLR -, the whole of the flag value is cleared to zero when the condition -is met. -cyg_flag_wait() takes -the following parameters: - - -flag - - -The value of the flag (set by the thread that called cyg_flag_setbits() or cyg_flag_maskbits()) -is placed in here. - - - -pattern - - -The set of bits which, if set, will cause the calling thread -to be woken up. - - - -mode - - -A parameter which modifies the conditions for wake-up. It -can take the following values: - - - -CYG_FLAG_WAITMODE_AND - - -Only wake up if all the bits in mask -are set in the flag. - - - -CYG_FLAG_WAITMODE_OR - - -Wake up if any of the bits in mask - are set in the flag. - - - -CYG_FLAG_WAITMODE_AND + - CYG_FLAG_WAITMODE_CLR -CYG_FLAG_WAITMODE_OR + CYG_FLAG_WAITMODE_CLR - - - Like CYG_FLAG_WAITMODE_AND and -CYG_FLAG_WAITMODE_OR, but the entire -flag is cleared to zero when the condition is met, whereas normally -the value of the flag is unchanged. - - - -Waiting threads are queued depending on the semantics of the -underlying scheduler. In release &version;, this means that, if -the multi-level queue scheduler is selected, queueing is in FIFO -ordering, while the bitmap scheduler supports thread priority ordered -queueing. When some flag value bits become signalled by a call to cyg_flag_setbits(), -the queue is scanned in order, and each waiting thread in turn is -awoken or re-queued depending on its request. When a thread is awoken, -if it made the wait call with CYG_FLAG_WAITMODE_CLR, -the flag value is cleared to zero, and the scan of queued threads -is terminated. -cyg_flag_value_t cyg_flag_timed_wait( - cyg_flag_t *flag, - cyg_flag_value_t pattern, - cyg_flag_mode_t mode, - cyg_tick_count_t abstime -) -A time-out version of cyg_flag_wait(). -This waits for the condition required by pattern -and mode to be met, or until the abstime - time-out is reached, whichever is first. -If the time-out is reached first, zero is returned. This call is -only available if the configuration option CYGFUN_KERNEL_THREADS_TIMER - is enabled. -cyg_flag_value_t cyg_flag_poll( - cyg_flag_t *flag, - cyg_flag_value_t pattern, - cyg_flag_mode_t mode -) -A non-blocking version of cyg_flag_wait(). -If the condition required by pattern and -mode is met, the flag value -is returned, otherwise zero is returned. The flag value may be cleared -in the event of success by specifying CYG_FLAG_WAITMODE_CLR -in the mode, as usual. -cyg_flag_value_t cyg_flag_peek( - cyg_flag_t *flag -) -Returns the current flag value. -cyg_bool_t cyg_flag_waiting( - cyg_flag_t *flag -) -Returns true if there are threads waiting on this flag. - - - -eCos <!-- <index></index> -->Interrupt Model -This chapter describes the eCos - interrupt model in detail. -Interrupt handling is an important part of most real-time - systems. Timely handling of interrupt sources is important. - This can be severely impacted by certain activities that must - be considered atomic (i.e. uninterruptible). Typically these - activities are executed with interrupts disabled. In order to - keep such activities to a minimum and allow for the smallest - possible interrupt latencies, eCos uses a - split interrupt handling scheme. In this scheme, interrupt - handling is separated into two parts. The first part is known - as the Interrupt Service Routine or - ISR. The second part is the Deferred - Service Routine or DSR. This separation explicitly allows for - the DSRs to be run with interrupts enabled, thus allowing - other potentially higher priority interrupts to occur and be - processed while processing a lower priority interrupt. -In order for this model to work, the ISR should run - quickly. If the service requirements for the interrupt are - small, the interrupt can be completely handled by the ISR and - no DSR is required. However, if servicing the interrupt is - more complex, a DSR should be used. The DSR will be run at - some later time, at the point when thread scheduling is - allowed. Postponing the execution of DSRs until this time - allows for simple synchronization methods to be used by the - kernel. -Further, this controlled calling — when thread scheduling -is allowed — means that DSRs can interact with the kernel, -for example by signalling that an asynchronous operation has completed. -In order to allow DSRs to run with interrupts enabled, the -ISR for a particular interrupt source (or the hardware) must arrange -that that interrupt will not recur until the DSR has completed. -In some cases, this is how the hardware works. Once an interrupt -is delivered another interrupt will not occur until re-enabled. -In the general case, however, it is up to the ISR to enforce this -behavior. Typically the ISR will "mask" the interrupt source, thus -preventing its recurrence. The DSR will then unmask the interrupt -when it has been serviced thus allowing new occurrences of the interrupt -to be delivered when they happen. -Alternatively, if an ISR is doing very little per interrupt, -for example transferring one byte from memory to an IO device, it -may only be necessary to interact with the rest of the system when -a "transfer" is complete. In such a case an ISR could execute many -times and only when it reaches the end of a buffer does it need -to request execution of its DSR. -If the interrupt source is "bursty", it may be OK for several -interrupts and calls to the ISR to occur before a requested DSR -has been executed; the kernel maintains counts for posted DSRs, -and in such a case the DSR will eventually be called with a parameter -that tells it how many ISRs requested that the DSR be called. Care -is needed to get the interrupt code right for such a situation, -for one call to the DSR is required to do the work of several. -As mentioned above, the DSR will execute at some later time. -Depending on the state of the system, it may be executed at a much -later time. There are periods during certain kernel operations where -thread scheduling is disabled, and hence DSRs are not allowed to -operate. These periods have been purposefully made as limited as -possible in the eCos kernel, but they still -exist. In addition, user threads have the ability to suspend scheduling -as well, thus affecting the possible DSR execution latency. If a -DSR cannot be executed sufficiently quickly, the interrupt source -may actually overrun. This would be considered a system failure. -One of the problems system designers face is how much stack -space to allow each thread in the system. eCos does -not dictate the size of thread stacks, it is left to the user when -the thread is created. The size of the stack depends on the thread -requirements as well as some fixed overhead required by the system. -In this case, the overhead is enough stack space to hold a complete -thread state (the actual amount depends on the CPU architecture). -Guidelines for the minimum stack requirements are provided by the HAL -using the symbol CYGNUM_HAL_STACK_SIZE_MINIMUM. -A potential problem with this scheme is with nested interrupts. -Since interrupts are reenabled during the DSR portion of servicing -an interrupt, there is the possibility of a new interrupt (hopefully -from a separate source) arriving while this processing takes place. -When this new interrupt is serviced some state information about -the interrupted processing will be saved on the stack. The amount -of this information again depends on the CPU architecture and in -some cases it is substantial. This implies that any given stack -would need enough space to potentially hold "N" interrupt frames. -In a realtime system with many threads this is an untenable situation. -To solve this problem, eCos allows for a separate -interrupt stack to be used while processing interrupts. This stack -needs to be large enough to support "N" nested interrupts, but each -individual thread stack only needs the overhead of a single interrupt -state. This is because the thread state is kept on the thread's -own stack, including information about any interrupt that caused -the thread to be scheduled. This is a much better situation in the -end, however, since only the interrupt stack need be large enough -to handle the potential interrupt servicing needs. -eCos allows for the use of the interrupt -stack to be totally configurable. The user can elect to not use -a separate interrupt stack. This requires making all thread stacks large -enough but does reduce the overhead of switching stacks while processing interrupts. -On the other hand, if memory is tight, then choosing a separate -interrupt stack would be warranted at the cost of a few machine -cycles during the processing of each interrupt. -Not all target HALs support this feature from day one anyway; -however common configuration features such as this may still be -presented in the config tool, and present in include files, even -if the actual target selected does not support the feature at this -time. -The following problem with the interrupt system has been observed. -On the mn10300 simulator, interrupts were occurring immediately -after they were re-enabled in the DSR. This should really be considered -a case of interrupt overrun since there is no possibility of useful [or -any] processing between the time an interrupt has been -serviced and an subsequent interrupt occurs, hence the system is totally -saturated. The problem came about because the stack was overflowing. -It was a user [thread] stack that overflowed because -DSR processing was taking place on the thread stack. Analysis of -this problem led to a rework of how interrupts are processed, in -particular the use of a separate interrupt stack during interrupt -processing (both ISR and DSR parts). The overflow can still happen, -but now it is restricted to only the interrupt stack. The system -designer can make accommodations for this by making a suitably large -interrupt stack if it is known that the "overrun" is finite, e.g. -in the case of a serial device, this could be the depth of some -FIFO. In any case, overrun should be avoided, but having only a -single stack that needs to suffer multiple interrupt frames allows -for this failure to be detected simply. -Of course, it is only worthwhile having a separate interrupt -stack if you are using an eCos configuration -that has a scheduler and multiple threads. If there is no kernel, -then the C library arranges to call main(), -or your application may be entered from cyg_user_start(), -on the startup stack. It runs on the only stack there is in the -system. Depending on the design of the particular HAL for your target -platform, it is natural to re-use the startup stack as the interrupt -stack as soon as the scheduler is running. Since this is only sensible -if there is a kernel, HALs typically only implement the separate interrupt -stack if the kernel is present. - - -<!-- <index></index> -->Real-time Characterization -When building a real-time system, care must be taken to - ensure that the system will be able to perform properly within - the constraints of that system. One of these constraints may - be how fast certain operations can be performed. Another might - be how deterministic the overall behavior of the system is. - Lastly the memory footprint (size) and unit cost may be - important. -One of the major problems encountered while evaluating a - system will be how to compare it with possible alternatives. - Most manufacturers of real-time systems publish performance - numbers, ostensibly so that users can compare the different - offerings. However, what these numbers mean and how they were - gathered is often not clear. The values are typically measured - on a particular piece of hardware, so in order to truly - compare, one must obtain measurements for exactly the same set - of hardware that were gathered in a similar fashion. -Two major items need to be present in any given set of - measurements. First, the raw values for the various - operations; these are typically quite easy to measure and will - be available for most systems. Second, the determinacy of the - numbers; in other words how much the value might change - depending on other factors within the system. This value is - affected by a number of factors: how long interrupts might be - masked, whether or not the function can be interrupted, even - very hardware-specific effects such as cache locality and - pipeline usage. It is very difficult to measure the - determinacy of any given operation, but that determinacy is - fundamentally important to proper overall characterization of - a system. -In the discussion and numbers that follow, three key measurements -are provided. The first measurement is an estimate of the interrupt + +Assume that after a certain period of time counter +has a value of 42, and two threads A and B running at the same +priority call process_event. Typically thread A +will read the value of counter into a register, +increment this register to 43, and write this updated value back to +memory. Thread B will do the same, so usually +counter will end up with a value of 44. However if +thread A is timesliced after reading the old value 42 but before +writing back 43, thread B will still read back the old value and will +also write back 43. The net result is that the counter only gets +incremented once, not twice, which depending on the application may +prove disastrous. + + +Sections of code like the above which involve manipulating shared data +are generally known as critical regions. Code should claim a lock +before entering a critical region and release the lock when leaving. +Mutexes provide an appropriate synchronization primitive for this. + + +static volatile int counter = 0; +static cyg_mutex_t lock; + +void +process_event(void) +{ + … + + cyg_mutex_lock(&lock); + counter++; + cyg_mutex_unlock(&lock); +} + + +A mutex must be initialized before it can be used, by calling +cyg_mutex_init. This takes a pointer to a +cyg_mutex_t data structure which is typically +statically allocated, and may be part of a larger data structure. If a +mutex is no longer required and there are no threads waiting on it +then cyg_mutex_destroy can be used. + + +The main functions for using a mutex are +cyg_mutex_lock and +cyg_mutex_unlock. In normal operation +cyg_mutex_lock will return success after claiming +the mutex lock, blocking if another thread currently owns the mutex. +However the lock operation may fail if other code calls +cyg_mutex_release or +cyg_thread_release, so if these functions may get +used then it is important to check the return value. The current owner +of a mutex should call cyg_mutex_unlock when a +lock is no longer required. This operation must be performed by the +owner, not by another thread. + + +cyg_mutex_trylock is a variant of +cyg_mutex_lock that will always return +immediately, returning success or failure as appropriate. This +function is rarely useful. Typical code locks a mutex just before +entering a critical region, so if the lock cannot be claimed then +there may be nothing else for the current thread to do. Use of this +function may also cause a form of priority inversion if the owner +owner runs at a lower priority, because the priority inheritance code +will not be triggered. Instead the current thread continues running, +preventing the owner from getting any cpu time, completing the +critical region, and releasing the mutex. + + +cyg_mutex_release can be used to wake up all +threads that are currently blocked inside a call to +cyg_mutex_lock for a specific mutex. These lock +calls will return failure. The current mutex owner is not affected. + + + + Priority Inversion + +The use of mutexes gives rise to a problem known as priority +inversion. In a typical scenario this requires three threads A, B, and +C, running at high, medium and low priority respectively. Thread A and +thread B are temporarily blocked waiting for some event, so thread C +gets a chance to run, needs to enter a critical region, and locks +a mutex. At this point threads A and B are woken up - the exact order +does not matter. Thread A needs to claim the same mutex but has to +wait until C has left the critical region and can release the mutex. +Meanwhile thread B works on something completely different and can +continue running without problems. Because thread C is running a lower +priority than B it will not get a chance to run until B blocks for +some reason, and hence thread A cannot run either. The overall effect +is that a high-priority thread A cannot proceed because of a lower +priority thread B, and priority inversion has occurred. + + +In simple applications it may be possible to arrange the code such +that priority inversion cannot occur, for example by ensuring that a +given mutex is never shared by threads running at different priority +levels. However this may not always be possible even at the +application level. In addition mutexes may be used internally by +underlying code, for example the memory allocation package, so careful +analysis of the whole system would be needed to be sure that priority +inversion cannot occur. Instead it is common practice to use one of +two techniques: priority ceilings and priority inheritance. + + +Priority ceilings involve associating a priority with each mutex. +Usually this will match the highest priority thread that will ever +lock the mutex. When a thread running at a lower priority makes a +successful call to cyg_mutex_lock or +cyg_mutex_trylock its priority will be boosted to +that of the mutex. For example, given the previous example the +priority associated with the mutex would be that of thread A, so for +as long as it owns the mutex thread C will run in preference to thread +B. When C releases the mutex its priority drops to the normal value +again, allowing A to run and claim the mutex. Setting the +priority for a mutex involves a call to +cyg_mutex_set_ceiling, which is typically called +during initialization. It is possible to change the ceiling +dynamically but this will only affect subsequent lock operations, not +the current owner of the mutex. + + +Priority ceilings are very suitable for simple applications, where for +every thread in the system it is possible to work out which mutexes +will be accessed. For more complicated applications this may prove +difficult, especially if thread priorities change at run-time. An +additional problem occurs for any mutexes outside the application, for +example used internally within eCos packages. A typical eCos package +will be unaware of the details of the various threads in the system, +so it will have no way of setting suitable ceilings for its internal +mutexes. If those mutexes are not exported to application code then +using priority ceilings may not be viable. The kernel does provide a +configuration option +CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_DEFAULT_PRIORITY +that can be used to set the default priority ceiling for all mutexes, +which may prove sufficient. + + +The alternative approach is to use priority inheritance: if a thread +calls cyg_mutex_lock for a mutex that it +currently owned by a lower-priority thread, then the owner will have +its priority raised to that of the current thread. Often this is more +efficient than priority ceilings because priority boosting only +happens when necessary, not for every lock operation, and the required +priority is determined at run-time rather than by static analysis. +However there are complications when multiple threads running at +different priorities try to lock a single mutex, or when the current +owner of a mutex then tries to lock additional mutexes, and this makes +the implementation significantly more complicated than priority +ceilings. + + +There are a number of configuration options associated with priority +inversion. First, if after careful analysis it is known that priority +inversion cannot arise then the component +CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL +can be disabled. More commonly this component will be enabled, and one +of either +CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_INHERIT +or +CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_CEILING +will be selected, so that one of the two protocols is available for +all mutexes. It is possible to select multiple protocols, so that some +mutexes can have priority ceilings while others use priority +inheritance or no priority inversion protection at all. Obviously this +flexibility will add to the code size and to the cost of mutex +operations. The default for all mutexes will be controlled by +CYGSEM_KERNEL_SYNCH_MUTEX_PRIORITY_INVERSION_PROTOCOL_DEFAULT, +and can be changed at run-time using +cyg_mutex_set_protocol. + + +Priority inversion problems can also occur with other synchronization +primitives such as semaphores. For example there could be a situation +where a high-priority thread A is waiting on a semaphore, a +low-priority thread C needs to do just a little bit more work before +posting the semaphore, but a medium priority thread B is running and +preventing C from making progress. However a semaphore does not have +the concept of an owner, so there is no way for the system to know +that it is thread C which would next post to the semaphore. Hence +there is no way for the system to boost the priority of C +automatically and prevent the priority inversion. Instead situations +like this have to be detected by application developers and +appropriate precautions have to be taken, for example making sure that +all the threads run at suitable priorities at all times. + + +The current implementation of priority inheritance within the eCos +kernel does not handle certain exceptional circumstances completely +correctly. Problems will only arise if a thread owns one mutex, +then attempts to claim another mutex, and there are other threads +attempting to lock these same mutexes. Although the system will +continue running, the current owners of the various mutexes involved +may not run at the priority they should. This situation never arises +in typical code because a mutex will only be locked for a small +critical region, and there is no need to manipulate other shared resources +inside this region. A more complicated implementation of priority +inheritance is possible but would add significant overhead and certain +operations would no longer be deterministic. + + +Support for priority ceilings and priority inheritance is not +implemented for all schedulers. In particular neither priority +ceilings nor priority inheritance are currently available for the +bitmap scheduler. + + + + Alternatives + +In nearly all circumstances, if two or more threads need to share some +data then protecting this data with a mutex is the correct thing to +do. Mutexes are the only primitive that combine a locking mechanism +and protection against priority inversion problems. However this +functionality is achieved at a cost, and in exceptional circumstances +such as an application's most critical inner loop it may be desirable +to use some other means of locking. + + +When a critical region is very very small it is possible to lock the +scheduler, thus ensuring that no other thread can run until the +scheduler is unlocked again. This is achieved with calls to cyg_scheduler_lock +and cyg_scheduler_unlock. If the critical region +is sufficiently small then this can actually improve both performance +and dispatch latency because cyg_mutex_lock also +locks the scheduler for a brief period of time. This approach will not +work on SMP systems because another thread may already be running on a +different processor and accessing the critical region. + + +Another way of avoiding the use of mutexes is to make sure that all +threads that access a particular critical region run at the same +priority and configure the system with timeslicing disabled +(CYGSEM_KERNEL_SCHED_TIMESLICE). Without +timeslicing a thread can only be preempted by a higher-priority one, +or if it performs some operation that can block. This approach +requires that none of the operations in the critical region can block, +so for example it is not legal to call +cyg_semaphore_wait. It is also vulnerable to +any changes in the configuration or to the various thread priorities: +any such changes may now have unexpected side effects. It will not +work on SMP systems. + + + + Recursive Mutexes + +The implementation of mutexes within the eCos kernel does not support +recursive locks. If a thread has locked a mutex and then attempts to +lock the mutex again, typically as a result of some recursive call in +a complicated call graph, then either an assertion failure will be +reported or the thread will deadlock. This behaviour is deliberate. +When a thread has just locked a mutex associated with some data +structure, it can assume that that data structure is in a consistent +state. Before unlocking the mutex again it must ensure that the data +structure is again in a consistent state. Recursive mutexes allow a +thread to make arbitrary changes to a data structure, then in a +recursive call lock the mutex again while the data structure is still +inconsistent. The net result is that code can no longer make any +assumptions about data structure consistency, which defeats the +purpose of using mutexes. + + + + Valid contexts + +cyg_mutex_init, +cyg_mutex_set_ceiling and +cyg_mutex_set_protocol are normally called during +initialization but may also be called from thread context. The +remaining functions should only be called from thread context. Mutexes +serve as a mutual exclusion mechanism between threads, and cannot be +used to synchronize between threads and the interrupt handling +subsystem. If a critical region is shared between a thread and a DSR +then it must be protected using cyg_scheduler_lock +and cyg_scheduler_unlock. If a critical region is +shared between a thread and an ISR, it must be protected by disabling +or masking interrupts. Obviously these operations must be used with +care because they can affect dispatch and interrupt latencies. + + + + + + + + + + + + Condition Variables + + + + cyg_cond_init + cyg_cond_destroy + cyg_cond_wait + cyg_cond_timed_wait + cyg_cond_signal + cyg_cond_broadcast + Synchronization primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_cond_init + cyg_cond_t* cond + cyg_mutex_t* mutex + + + void cyg_cond_destroy + cyg_cond_t* cond + + + cyg_bool_t cyg_cond_wait + cyg_cond_t* cond + + + cyg_bool_t cyg_cond_timed_wait + cyg_cond_t* cond + cyg_tick_count_t abstime + + + void cyg_cond_signal + cyg_cond_t* cond + + + void cyg_cond_broadcast + cyg_cond_t* cond + + + + + Description + + +Condition variables are used in conjunction with mutexes to implement +long-term waits for some condition to become true. For example +consider a set of functions that control access to a pool of +resources: + + + + +cyg_mutex_t res_lock; +res_t res_pool[RES_MAX]; +int res_count = RES_MAX; + +void res_init(void) +{ + cyg_mutex_init(&res_lock); + <fill pool with resources> +} + +res_t res_allocate(void) +{ + res_t res; + + cyg_mutex_lock(&res_lock); // lock the mutex + + if( res_count == 0 ) // check for free resource + res = RES_NONE; // return RES_NONE if none + else + { + res_count--; // allocate a resources + res = res_pool[res_count]; + } + + cyg_mutex_unlock(&res_lock); // unlock the mutex + + return res; +} + +void res_free(res_t res) +{ + cyg_mutex_lock(&res_lock); // lock the mutex + + res_pool[res_count] = res; // free the resource + res_count++; + + cyg_mutex_unlock(&res_lock); // unlock the mutex +} + + + +These routines use the variable res_count to keep +track of the resources available. If there are none then +res_allocate returns RES_NONE, +which the caller must check for and take appropriate error handling +actions. + + + +Now suppose that we do not want to return +RES_NONE when there are no resources, but want to +wait for one to become available. This is where a condition variable +can be used: + + + + +cyg_mutex_t res_lock; +cyg_cond_t res_wait; +res_t res_pool[RES_MAX]; +int res_count = RES_MAX; + +void res_init(void) +{ + cyg_mutex_init(&res_lock); + cyg_cond_init(&res_wait, &res_lock); + <fill pool with resources> +} + +res_t res_allocate(void) +{ + res_t res; + + cyg_mutex_lock(&res_lock); // lock the mutex + + while( res_count == 0 ) // wait for a resources + cyg_cond_wait(&res_wait); + + res_count--; // allocate a resource + res = res_pool[res_count]; + + cyg_mutex_unlock(&res_lock); // unlock the mutex + + return res; +} + +void res_free(res_t res) +{ + cyg_mutex_lock(&res_lock); // lock the mutex + + res_pool[res_count] = res; // free the resource + res_count++; + + cyg_cond_signal(&res_wait); // wake up any waiting allocators + + cyg_mutex_unlock(&res_lock); // unlock the mutex +} + + + +In this version of the code, when res_allocate +detects that there are no resources it calls +cyg_cond_wait. This does two things: it unlocks +the mutex, and puts the calling thread to sleep on the condition +variable. When res_free is eventually called, it +puts a resource back into the pool and calls +cyg_cond_signal to wake up any thread waiting on +the condition variable. When the waiting thread eventually gets to run again, +it will re-lock the mutex before returning from +cyg_cond_wait. + + + +There are two important things to note about the way in which this +code works. The first is that the mutex unlock and wait in +cyg_cond_wait are atomic: no other thread can run +between the unlock and the wait. If this were not the case then a call +to res_free by that thread would release the +resource but the call to cyg_cond_signal would be +lost, and the first thread would end up waiting when there were +resources available. + + + +The second feature is that the call to +cyg_cond_wait is in a while +loop and not a simple if statement. This is because +of the need to re-lock the mutex in cyg_cond_wait +when the signalled thread reawakens. If there are other threads +already queued to claim the lock then this thread must wait. Depending +on the scheduler and the queue order, many other threads may have +entered the critical section before this one gets to run. So the +condition that it was waiting for may have been rendered false. Using +a loop around all condition variable wait operations is the only way +to guarantee that the condition being waited for is still true after +waiting. + + + +Before a condition variable can be used it must be initialized with a +call to cyg_cond_init. This requires two +arguments, memory for the data structure and a pointer to an existing +mutex. This mutex will not be initialized by +cyg_cond_init, instead a separate call to +cyg_mutex_init is required. If a condition +variable is no longer required and there are no threads waiting on it +then cyg_cond_destroy can be used. + + +When a thread needs to wait for a condition to be satisfied it can +call cyg_cond_wait. The thread must have already +locked the mutex that was specified in the +cyg_cond_init call. This mutex will be unlocked +and the current thread will be suspended in an atomic operation. When +some other thread performs a signal or broadcast operation the current +thread will be woken up and automatically reclaim ownership of the mutex +again, allowing it to examine global state and determine whether or +not the condition is now satisfied. The kernel supplies a variant of +this function, cyg_cond_timed_wait, which can be +used to wait on the condition variable or until some number of clock +ticks have occurred. The mutex will always be reclaimed before +cyg_cond_timed_wait returns, regardless of +whether it was a result of a signal operation or a timeout. + + +There is no cyg_cond_trywait function because +this would not serve any purpose. If a thread has locked the mutex and +determined that the condition is satisfied, it can just release the +mutex and return. There is no need to perform any operation on the +condition variable. + + +When a thread changes shared state that may affect some other thread +blocked on a condition variable, it should call either +cyg_cond_signal or +cyg_cond_broadcast. These calls do not require +ownership of the mutex, but usually the mutex will have been claimed +before updating the shared state. A signal operation only wakes up the +first thread that is waiting on the condition variable, while a +broadcast wakes up all the threads. If there are no threads waiting on +the condition variable at the time, then the signal or broadcast will +have no effect: past signals are not counted up or remembered in any +way. Typically a signal should be used when all threads will check the +same condition and at most one thread can continue running. A +broadcast should be used if threads check slightly different +conditions, or if the change to the global state might allow multiple +threads to proceed. + + + + Valid contexts + +cyg_cond_init is typically called during system +initialization but may also be called in thread context. The same +applies to cyg_cond_delete. +cyg_cond_wait and +cyg_cond_timedwait may only be called from thread +context since they may block. cyg_cond_signal and +cyg_cond_broadcast may be called from thread or +DSR context. + + + + + + + + + + + + Semaphores + + + + cyg_semaphore_init + cyg_semaphore_destroy + cyg_semaphore_wait + cyg_semaphore_timed_wait + cyg_semaphore_post + cyg_semaphore_peek + Synchronization primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_semaphore_init + cyg_sem_t* sem + cyg_count32 val + + + void cyg_semaphore_destroy + cyg_sem_t* sem + + + cyg_bool_t cyg_semaphore_wait + cyg_sem_t* sem + + + cyg_bool_t cyg_semaphore_timed_wait + cyg_sem_t* sem + cyg_tick_count_t abstime + + + cyg_bool_t cyg_semaphore_trywait + cyg_sem_t* sem + + + void cyg_semaphore_post + cyg_sem_t* sem + + + void cyg_semaphore_peek + cyg_sem_t* sem + cyg_count32* val + + + + + Description + +Counting semaphores are a synchronization +primitive that allow threads to wait until an event has +occurred. The event may be generated by a producer thread, or by a DSR +in response to a hardware interrupt. Associated with each semaphore is +an integer counter that keeps track of the number of events that have +not yet been processed. If this counter is zero, an attempt by a +consumer thread to wait on the semaphore will block until some other +thread or a DSR posts a new event to the semaphore. If the counter is +greater than zero then an attempt to wait on the semaphore will +consume one event, in other words decrement the counter, and return +immediately. Posting to a semaphore will wake up the first thread that +is currently waiting, which will then resume inside the semaphore wait +operation and decrement the counter again. + + +Another use of semaphores is for certain forms of resource management. +The counter would correspond to how many of a certain type of resource +are currently available, with threads waiting on the semaphore to +claim a resource and posting to release the resource again. In +practice condition +variables are usually much better suited for operations like +this. + + +cyg_semaphore_init is used to initialize a +semaphore. It takes two arguments, a pointer to a +cyg_sem_t structure and an initial value for +the counter. Note that semaphore operations, unlike some other parts +of the kernel API, use pointers to data structures rather than +handles. This makes it easier to embed semaphores in a larger data +structure. The initial counter value can be any number, zero, positive +or negative, but typically a value of zero is used to indicate that no +events have occurred yet. + + +cyg_semaphore_wait is used by a consumer thread +to wait for an event. If the current counter is greater than 0, in +other words if the event has already occurred in the past, then the +counter will be decremented and the call will return immediately. +Otherwise the current thread will be blocked until there is a +cyg_semaphore_post call. + + +cyg_semaphore_post is called when an event has +occurs. This increments the counter and wakes up the first thread +waiting on the semaphore (if any). Usually that thread will then +continue running inside cyg_semaphore_wait and +decrement the counter again. However other scenarioes are possible. +For example the thread calling cyg_semaphore_post +may be running at high priority, some other thread running at medium +priority may be about to call cyg_semaphore_wait +when it next gets a chance to run, and a low priority thread may be +waiting on the semaphore. What will happen is that the current high +priority thread continues running until it is descheduled for some +reason, then the medium priority thread runs and its call to +cyg_semaphore_wait succeeds immediately, and +later on the low priority thread runs again, discovers a counter value +of 0, and blocks until another event is posted. If there are multiple +threads blocked on a semaphore then the configuration option +CYGIMP_KERNEL_SCHED_SORTED_QUEUES determines which +one will be woken up by a post operation. + + +cyg_semaphore_wait returns a boolean. Normally it +will block until it has successfully decremented the counter, retrying +as necessary, and return success. However the wait operation may be +aborted by a call to cyg_thread_release, +and cyg_semaphore_wait will then return false. + + +cyg_semaphore_timed_wait is a variant of +cyg_semaphore_wait. It can be used to wait until +either an event has occurred or a number of clock ticks have happened. +The function returns success if the semaphore wait operation +succeeded, or false if the operation timed out or was aborted by +cyg_thread_release. If support for the real-time +clock has been removed from the current configuration then this +function will not be available. +cyg_semaphore_trywait is another variant which +will always return immediately rather than block, again returning +success or failure. + + +cyg_semaphore_peek can be used to get hold of the +current counter value. This function is rarely useful except for +debugging purposes since the counter value may change at any time if +some other thread or a DSR performs a semaphore operation. + + + + Valid contexts + +cyg_semaphore_init is normally called during +initialization but may also be called from thread context. +cyg_semaphore_wait and +cyg_semaphore_timed_wait may only be called from +thread context because these operations may block. +cyg_semaphore_trywait, +cyg_semaphore_post and +cyg_semaphore_peek may be called from thread or +DSR context. + + + + + + + + + + + + Mail boxes + + + + cyg_mbox_create + cyg_mbox_delete + cyg_mbox_get + cyg_mbox_timed_get + cyg_mbox_tryget + cyg_mbox_peek_item + cyg_mbox_put + cyg_mbox_timed_put + cyg_mbox_tryput + cyg_mbox_peek + cyg_mbox_waiting_to_get + cyg_mbox_waiting_to_put + Synchronization primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_mbox_create + cyg_handle_t* handle + cyg_mbox* mbox + + + void cyg_mbox_delete + cyg_handle_t mbox + + + void* cyg_mbox_get + cyg_handle_t mbox + + + void* cyg_mbox_timed_get + cyg_handle_t mbox + cyg_tick_count_t abstime + + + void* cyg_mbox_tryget + cyg_handle_t mbox + + + cyg_count32 cyg_mbox_peek + cyg_handle_t mbox + + + void* cyg_mbox_peek_item + cyg_handle_t mbox + + + cyg_bool_t cyg_mbox_put + cyg_handle_t mbox + void* item + + + cyg_bool_t cyg_mbox_timed_put + cyg_handle_t mbox + void* item + cyg_tick_count_t abstime + + + cyg_bool_t cyg_mbox_tryput + cyg_handle_t mbox + void* item + + + cyg_bool_t cyg_mbox_waiting_to_get + cyg_handle_t mbox + + + cyg_bool_t cyg_mbox_waiting_to_put + cyg_handle_t mbox + + + + + Description + +Mail boxes are a synchronization primitive. Like semaphores they +can be used by a consumer thread to wait until a certain event has +occurred, but the producer also has the ability to transmit some data +along with each event. This data, the message, is normally a pointer +to some data structure. It is stored in the mail box itself, so the +producer thread that generates the event and provides the data usually +does not have to block until some consumer thread is ready to receive +the event. However a mail box will only have a finite capacity, +typically ten slots. Even if the system is balanced and events are +typically consumed at least as fast as they are generated, a burst of +events can cause the mail box to fill up and the generating thread +will block until space is available again. This behaviour is very +different from semaphores, where it is only necessary to maintain a +counter and hence an overflow is unlikely. + + +Before a mail box can be used it must be created with a call to +cyg_mbox_create. Each mail box has a unique +handle which will be returned via the first argument and which should +be used for subsequent operations. +cyg_mbox_create also requires an area of memory +for the kernel structure, which is provided by the +cyg_mbox second argument. If a mail box is +no longer required then cyg_mbox_delete can be +used. This will simply discard any messages that remain posted. + + +The main function for waiting on a mail box is +cyg_mbox_get. If there is a pending message +because of a call to cyg_mbox_put then +cyg_mbox_get will return immediately with the +message that was put into the mail box. Otherwise this function +will block until there is a put operation. Exceptionally the thread +can instead be unblocked by a call to +cyg_thread_release, in which case +cyg_mbox_get will return a null pointer. It is +assumed that there will never be a call to +cyg_mbox_put with a null pointer, because it +would not be possible to distinguish between that and a release +operation. Messages are always retrieved in the order in which they +were put into the mail box, and there is no support for messages +with different priorities. + + +There are two variants of cyg_mbox_get. The +first, cyg_mbox_timed_get will wait until either +a message is available or until a number of clock ticks have occurred. +If no message is posted within the timeout then a null pointer will be +returned. cyg_mbox_tryget is a non-blocking +operation which will either return a message if one is available or a +null pointer. + + +New messages are placed in the mail box by calling +cyg_mbox_put or one of its variants. The main put +function takes two arguments, a handle to the mail box and a +pointer for the message itself. If there is a spare slot in the +mail box then the new message can be placed there immediately, and +if there is a waiting thread it will be woken up so that it can +receive the message. If the mail box is currently full then +cyg_mbox_put will block until there has been a +get operation and a slot is available. The +cyg_mbox_timed_put variant imposes a time limit +on the put operation, returning false if the operation cannot be +completed within the specified number of clock ticks. The +cyg_mbox_tryput variant is non-blocking, +returning false if there are no free slots available and the message +cannot be posted without blocking. + + +There are a further four functions available for examining the current +state of a mailbox. The results of these functions must be used with +care because usually the state can change at any time as a result of +activity within other threads, but they may prove occasionally useful +during debugging or in special situations. +cyg_mbox_peek returns a count of the number of +messages currently stored in the mail box. +cyg_mbox_peek_item retrieves the first message, +but it remains in the mail box until a get operation is performed. +cyg_mbox_waiting_to_get and +cyg_mbox_waiting_to_put indicate whether or not +there are currently threads blocked in a get or a put operation on a +given mail box. + + +The number of slots in each mail box is controlled by a +configuration option +CYGNUM_KERNEL_SYNCH_MBOX_QUEUE_SIZE, with a default +value of 10. All mail boxes are the same size. + + + + Valid contexts + +cyg_mbox_create is typically called during +system initialization but may also be called in thread context. +The remaining functions are normally called only during thread +context. Of special note is cyg_mbox_put which +can be a blocking operation when the mail box is full, and which +therefore must never be called from DSR context. It is permitted to +call cyg_mbox_tryput, +cyg_mbox_tryget, and the information functions +from DSR context but this is rarely useful. + + + + + + + + + + + + Event Flags + + + + cyg_flag_init + cyg_flag_destroy + cyg_flag_setbits + cyg_flag_maskbits + cyg_flag_wait + cyg_flag_timed_wait + cyg_flag_poll + cyg_flag_peek + cyg_flag_waiting + Synchronization primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_flag_init + cyg_flag_t* flag + + + void cyg_flag_destroy + cyg_flag_t* flag + + + void cyg_flag_setbits + cyg_flag_t* flag + cyg_flag_value_t value + + + void cyg_flag_maskbits + cyg_flag_t* flag + cyg_flag_value_t value + + + cyg_flag_value_t cyg_flag_wait + cyg_flag_t* flag + cyg_flag_value_t pattern + cyg_flag_mode_t mode + + + cyg_flag_value_t cyg_flag_timed_wait + cyg_flag_t* flag + cyg_flag_value_t pattern + cyg_flag_mode_t mode + cyg_tick_count_t abstime + + + cyg_flag_value_t cyg_flag_poll + cyg_flag_t* flag + cyg_flag_value_t pattern + cyg_flag_mode_t mode + + + cyg_flag_value_t cyg_flag_peek + cyg_flag_t* flag + + + cyg_bool_t cyg_flag_waiting + cyg_flag_t* flag + + + + + Description + +Event flags allow a consumer thread to wait for one of several +different types of event to occur. Alternatively it is possible to +wait for some combination of events. The implementation is relatively +straightforward. Each event flag contains a 32-bit integer. +Application code associates these bits with specific events, so for +example bit 0 could indicate that an I/O operation has completed and +data is available, while bit 1 could indicate that the user has +pressed a start button. A producer thread or a DSR can cause one or +more of the bits to be set, and a consumer thread currently waiting +for these bits will be woken up. + + +Unlike semaphores no attempt is made to keep track of event counts. It +does not matter whether a given event occurs once or multiple times +before being consumed, the corresponding bit in the event flag will +change only once. However semaphores cannot easily be used to handle +multiple event sources. Event flags can often be used as an +alternative to condition variables, although they cannot be used for +completely arbitrary conditions and they only support the equivalent +of condition variable broadcasts, not signals. + + +Before an event flag can be used it must be initialized by a call to +cyg_flag_init. This takes a pointer to a +cyg_flag_t data structure, which can be part of a +larger structure. All 32 bits in the event flag will be set to 0, +indicating that no events have yet occurred. If an event flag is no +longer required it can be cleaned up with a call to +cyg_flag_destroy, allowing the memory for the +cyg_flag_t structure to be re-used. + + +A consumer thread can wait for one or more events by calling +cyg_flag_wait. This takes three arguments. The +first identifies a particular event flag. The second is some +combination of bits, indicating which events are of interest. The +final argument should be one of the following: + + + + CYG_FLAG_WAITMODE_AND + +The call to cyg_flag_wait will block until all +the specified event bits are set. The event flag is not cleared when +the wait succeeds, in other words all the bits remain set. + + + + CYG_FLAG_WAITMODE_OR + +The call will block until at least one of the specified event bits is +set. The event flag is not cleared on return. + + + + CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR + +The call will block until all the specified event bits are set, and +the entire event flag is cleared when the call succeeds. Note that +if this mode of operation is used then a single event flag cannot be +used to store disjoint sets of events, even though enough bits might +be available. Instead each disjoint set of events requires its own +event flag. + + + + CYG_FLAG_WAITMODE_OR | CYG_FLAG_WAITMODE_CLR + +The call will block until at least one of the specified event bits is +set, and the entire flag is cleared when the call succeeds. + + + + +A call to cyg_flag_wait normally blocks until the +required condition is satisfied. It will return the value of the event +flag at the point that the operation succeeded, which may be a +superset of the requested events. If +cyg_thread_release is used to unblock a thread +that is currently in a wait operation, the +cyg_flag_wait call will instead return 0. + + +cyg_flag_timed_wait is a variant of +cyg_flag_wait which adds a timeout: the wait +operation must succeed within the specified number of ticks, or it +will fail with a return value of 0. cyg_flag_poll +is a non-blocking variant: if the wait operation can succeed +immediately it acts like cyg_flag_wait, otherwise +it returns immediately with a value of 0. + + +cyg_flag_setbits is called by a producer thread +or from inside a DSR when an event occurs. The specified bits are or'd +into the current event flag value. This may cause a waiting thread to +be woken up, if its condition is now satisfied. + + +cyg_flag_maskbits can be used to clear one or +more bits in the event flag. This can be called from a producer when a +particular condition is no longer satisfied, for example when the user +is no longer pressing a particular button. It can also be used by a +consumer thread if CYG_FLAG_WAITMODE_CLR was not +used as part of the wait operation, to indicate that some but not all +of the active events have been consumed. If there are multiple +consumer threads performing wait operations without using +CYG_FLAG_WAITMODE_CLR then typically some +additional synchronization such as a mutex is needed to prevent +multiple threads consuming the same event. + + +Two additional functions are provided to query the current state of an +event flag. cyg_flag_peek returns the current +value of the event flag, and cyg_flag_waiting can +be used to find out whether or not there are any threads currently +blocked on the event flag. Both of these functions must be used with +care because other threads may be operating on the event flag. + + + + Valid contexts + +cyg_flag_init is typically called during system +initialization but may also be called in thread context. The same +applies to cyg_flag_destroy. +cyg_flag_wait and +cyg_flag_timed_wait may only be called from +thread context. The remaining functions may be called from thread or +DSR context. + + + + + + + + + + + + Spinlocks + + + + cyg_spinlock_create + cyg_spinlock_destroy + cyg_spinlock_spin + cyg_spinlock_clear + cyg_spinlock_test + cyg_spinlock_spin_intsave + cyg_spinlock_clear_intsave + Low-level Synchronization Primitive + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_spinlock_init + cyg_spinlock_t* lock + cyg_bool_t locked + + + void cyg_spinlock_destroy + cyg_spinlock_t* lock + + + void cyg_spinlock_spin + cyg_spinlock_t* lock + + + void cyg_spinlock_clear + cyg_spinlock_t* lock + + + cyg_bool_t cyg_spinlock_try + cyg_spinlock_t* lock + + + cyg_bool_t cyg_spinlock_test + cyg_spinlock_t* lock + + + void cyg_spinlock_spin_intsave + cyg_spinlock_t* lock + cyg_addrword_t* istate + + + void cyg_spinlock_clear_intsave + cyg_spinlock_t* lock + cyg_addrword_t istate + + + + + Description + +Spinlocks provide an additional synchronization primitive for +applications running on SMP systems. They operate at a lower level +than the other primitives such as mutexes, and for most purposes the +higher-level primitives should be preferred. However there are some +circumstances where a spinlock is appropriate, especially when +interrupt handlers and threads need to share access to hardware, and +on SMP systems the kernel implementation itself depends on spinlocks. + + +Essentially a spinlock is just a simple flag. When code tries to claim +a spinlock it checks whether or not the flag is already set. If not +then the flag is set and the operation succeeds immediately. The exact +implementation of this is hardware-specific, for example it may use a +test-and-set instruction to guarantee the desired behaviour even if +several processors try to access the spinlock at the exact same time. +If it is not possible to claim a spinlock then the current thead spins +in a tight loop, repeatedly checking the flag until it is clear. This +behaviour is very different from other synchronization primitives such +as mutexes, where contention would cause a thread to be suspended. The +assumption is that a spinlock will only be held for a very short time. +If claiming a spinlock could cause the current thread to be suspended +then spinlocks could not be used inside interrupt handlers, which is +not acceptable. + + +This does impose a constraint on any code which uses spinlocks. +Specifically it is important that spinlocks are held only for a short +period of time, typically just some dozens of instructions. Otherwise +another processor could be blocked on the spinlock for a long time, +unable to do any useful work. It is also important that a thread which +owns a spinlock does not get preempted because that might cause +another processor to spin for a whole timeslice period, or longer. One +way of achieving this is to disable interrupts on the current +processor, and the function +cyg_spinlock_spin_intsave is provided to +facilitate this. + + +Spinlocks should not be used on single-processor systems. Consider a +high priority thread which attempts to claim a spinlock already held +by a lower priority thread: it will just loop forever and the lower +priority thread will never get another chance to run and release the +spinlock. Even if the two threads were running at the same priority, +the one attempting to claim the spinlock would spin until it was +timesliced and a lot of cpu time would be wasted. If an interrupt +handler tried to claim a spinlock owned by a thread, the interrupt +handler would loop forever. Therefore spinlocks are only appropriate +for SMP systems where the current owner of a spinlock can continue +running on a different processor. + + +Before a spinlock can be used it must be initialized by a call to +cyg_spinlock_init. This takes two arguments, a +pointer to a cyg_spinlock_t data structure, and +a flag to specify whether the spinlock starts off locked or unlocked. +If a spinlock is no longer required then it can be destroyed by a call +to cyg_spinlock_destroy. + + +There are two routines for claiming a spinlock: +cyg_spinlock_spin and +cyg_spinlock_spin_intsave. The former can be used +when it is known the current code will not be preempted, for example +because it is running in an interrupt handler or because interrupts +are disabled. The latter will disable interrupts in addition to +claiming the spinlock, so is safe to use in all circumstances. The +previous interrupt state is returned via the second argument, and +should be used in a subsequent call to +cyg_spinlock_clear_intsave. + + +Similarly there are two routines for releasing a spinlock: +cyg_spinlock_clear and +cyg_spinlock_clear_intsave. Typically +the former will be used if the spinlock was claimed by a call to +cyg_spinlock_spin, and the latter when +cyg_spinlock_intsave was used. + + +There are two additional routines. +cyg_spinlock_try is a non-blocking version of +cyg_spinlock_spin: if possible the lock will be +claimed and the function will return true; otherwise the function +will return immediately with failure. +cyg_spinlock_test can be used to find out whether +or not the spinlock is currently locked. This function must be used +with care because, especially on a multiprocessor system, the state of +the spinlock can change at any time. + + +Spinlocks should only be held for a short period of time, and +attempting to claim a spinlock will never cause a thread to be +suspended. This means that there is no need to worry about priority +inversion problems, and concepts such as priority ceilings and +inheritance do not apply. + + + + Valid contexts + +All of the spinlock functions can be called from any context, +including ISR and DSR context. Typically +cyg_spinlock_init is only called during system +initialization. + + + + + + + + + + + + Scheduler Control + + + + cyg_scheduler_start + cyg_scheduler_lock + cyg_scheduler_unlock + cyg_scheduler_safe_lock + cyg_scheduler_read_lock + Control the state of the scheduler + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_scheduler_start + + + + void cyg_scheduler_lock + + + + void cyg_scheduler_unlock + + + + cyg_ucount32 cyg_scheduler_read_lock + + + + + + Description + +cyg_scheduler_start should only be called once, +to mark the end of system initialization. In typical configurations it +is called automatically by the system startup, but some applications +may bypass the standard startup in which case +cyg_scheduler_start will have to be called +explicitly. The call will enable system interrupts, allowing I/O +operations to commence. Then the scheduler will be invoked and control +will be transferred to the highest priority runnable thread. The call +will never return. + + +The various data structures inside the eCos kernel must be protected +against concurrent updates. Consider a call to +cyg_semaphore_post which causes a thread to be +woken up: the semaphore data structure must be updated to remove the +thread from its queue; the scheduler data structure must also be +updated to mark the thread as runnable; it is possible that the newly +runnable thread has a higher priority than the current one, in which +case preemption is required. If in the middle of the semaphore post +call an interrupt occurred and the interrupt handler tried to +manipulate the same data structures, for example by making another +thread runnable, then it is likely that the structures will be left in +an inconsistent state and the system will fail. + + +To prevent such problems the kernel contains a special lock known as +the scheduler lock. A typical kernel function such as +cyg_semaphore_post will claim the scheduler lock, +do all its manipulation of kernel data structures, and then release +the scheduler lock. The current thread cannot be preempted while it +holds the scheduler lock. If an interrupt occurs and a DSR is supposed +to run to signal that some event has occurred, that DSR is postponed +until the scheduler unlock operation. This prevents concurrent updates +of kernel data structures. + + +The kernel exports three routines for manipulating the scheduler lock. +cyg_scheduler_lock can be called to claim the +lock. On return it is guaranteed that the current thread will not be +preempted, and that no other code is manipulating any kernel data +structures. cyg_scheduler_unlock can be used to +release the lock, which may cause the current thread to be preempted. +cyg_scheduler_read_lock can be used to query the +current state of the scheduler lock. This function should never be +needed because well-written code should always know whether or not the +scheduler is currently locked, but may prove useful during debugging. + + +The implementation of the scheduler lock involves a simple counter. +Code can call cyg_scheduler_lock multiple times, +causing the counter to be incremented each time, as long as +cyg_scheduler_unlock is called the same number of +times. This behaviour is different from mutexes where an attempt by a +thread to lock a mutex multiple times will result in deadlock or an +assertion failure. + + +Typical application code should not use the scheduler lock. Instead +other synchronization primitives such as mutexes and semaphores should +be used. While the scheduler is locked the current thread cannot be +preempted, so any higher priority threads will not be able to run. +Also no DSRs can run, so device drivers may not be able to service +I/O requests. However there is one situation where locking the +scheduler is appropriate: if some data structure needs to be shared +between an application thread and a DSR associated with some interrupt +source, the thread can use the scheduler lock to prevent concurrent +invocations of the DSR and then safely manipulate the structure. It is +desirable that the scheduler lock is held for only a short period of +time, typically some tens of instructions. In exceptional cases there +may also be some performance-critical code where it is more +appropriate to use the scheduler lock rather than a mutex, because the +former is more efficient. + + + + Valid contexts + +cyg_scheduler_start can only be called during +system initialization, since it marks the end of that phase. The +remaining functions may be called from thread or DSR context. Locking +the scheduler from inside the DSR has no practical effect because the +lock is claimed automatically by the interrupt subsystem before +running DSRs, but allows functions to be shared between normal thread +code and DSRs. + + + + + + + + + + + + Interrupt Handling + + + + cyg_interrupt_create + cyg_interrupt_delete + cyg_interrupt_attach + cyg_interrupt_detach + cyg_interrupt_configure + cyg_interrupt_acknowledge + cyg_interrupt_enable + cyg_interrupt_disable + cyg_interrupt_mask + cyg_interrupt_mask_intunsafe + cyg_interrupt_unmask + cyg_interrupt_unmask_intunsafe + cyg_interrupt_set_cpu + cyg_interrupt_get_cpu + cyg_interrupt_get_vsr + cyg_interrupt_set_vsr + Manage interrupt handlers + + + + + +#include <cyg/kernel/kapi.h> + + + void cyg_interrupt_create + cyg_vector_t vector + cyg_priority_t priority + cyg_addrword_t data + cyg_ISR_t* isr + cyg_DSR_t* dsr + cyg_handle_t* handle + cyg_interrupt* intr + + + void cyg_interrupt_delete + cyg_handle_t interrupt + + + void cyg_interrupt_attach + cyg_handle_t interrupt + + + void cyg_interrupt_detach + cyg_handle_t interrupt + + + void cyg_interrupt_configure + cyg_vector_t vector + cyg_bool_t level + cyg_bool_t up + + + void cyg_interrupt_acknowledge + cyg_vector_t vector + + + void cyg_interrupt_disable + + + + void cyg_interrupt_enable + + + + void cyg_interrupt_mask + cyg_vector_t vector + + + void cyg_interrupt_mask_intunsafe + cyg_vector_t vector + + + void cyg_interrupt_unmask + cyg_vector_t vector + + + void cyg_interrupt_unmask_intunsafe + cyg_vector_t vector + + + void cyg_interrupt_set_cpu + cyg_vector_t vector + cyg_cpu_t cpu + + + cyg_cpu_t cyg_interrupt_get_cpu + cyg_vector_t vector + + + void cyg_interrupt_get_vsr + cyg_vector_t vector + cyg_VSR_t** vsr + + + void cyg_interrupt_set_vsr + cyg_vector_t vector + cyg_VSR_t* vsr + + + + + Description + +The kernel provides an interface for installing interrupt handlers and +controlling when interrupts occur. This functionality is used +primarily by eCos device drivers and by any application code that +interacts directly with hardware. However in most cases it is better +to avoid using this kernel functionality directly, and instead the +device driver API provided by the common HAL package should be used. +Use of the kernel package is optional, and some applications such as +RedBoot work with no need for multiple threads or synchronization +primitives. Any code which calls the kernel directly rather than the +device driver API will not function in such a configuration. When the +kernel package is present the device driver API is implemented as +#define's to the equivalent kernel calls, otherwise +it is implemented inside the common HAL package. The latter +implementation can be simpler than the kernel one because there is no +need to consider thread preemption and similar issues. + + +The exact details of interrupt handling vary widely between +architectures. The functionality provided by the kernel abstracts away +from many of the details of the underlying hardware, thus simplifying +application development. However this is not always successful. For +example, if some hardware does not provide any support at all for +masking specific interrupts then calling +cyg_interrupt_mask may not behave as intended: +instead of masking just the one interrupt source it might disable all +interrupts, because that is as close to the desired behaviour as is +possible given the hardware restrictions. Another possibility is that +masking a given interrupt source also affects all lower-priority +interrupts, but still allows higher-priority ones. The documentation +for the appropriate HAL packages should be consulted for more +information about exactly how interrupts are handled on any given +hardware. The HAL header files will also contain useful information. + + + + Interrupt Handlers + +Interrupt handlers are created by a call to +cyg_interrupt_create. This takes the following +arguments: + + + + cyg_vector_t vector + +The interrupt vector, a small integer, identifies the specific +interrupt source. The appropriate hardware documentation or HAL header +files should be consulted for details of which vector corresponds to +which device. + + + + cyg_priority_t priority + +Some hardware may support interrupt priorities, where a low priority +interrupt handler can in turn be interrupted by a higher priority one. +Again hardware-specific documentation should be consulted for details +about what the valid interrupt priority levels are. + + + + cyg_addrword_t data + +When an interrupt occurs eCos will first call the associated +interrupt service routine or ISR, then optionally a deferred service +routine or DSR. The data argument to +cyg_interrupt_create will be passed to both these +functions. Typically it will be a pointer to some data structure. + + + + cyg_ISR_t isr + +When an interrupt occurs the hardware will transfer control to the +appropriate vector service routine or VSR, which is usually provided +by eCos. This performs any appropriate processing, for example to work +out exactly which interrupt occurred, and then as quickly as possible +transfers control the installed ISR. An ISR is a C function which +takes the following form: + + +cyg_uint32 +isr_function(cyg_vector_t vector, cyg_addrword_t data) +{ + cyg_bool_t dsr_required = 0; + + … + + return dsr_required ? CYG_ISR_CALL_DSR : CYG_ISR_HANDLED; +} + + +The first argument identifies the particular interrupt source, +especially useful if there multiple instances of a given device and a +single ISR can be used for several different interrupt vectors. The +second argument is the data field passed to +cyg_interrupt_create, usually a pointer to some +data structure. The exact conditions under which an ISR runs will +depend partly on the hardware and partly on configuration options. +Interrupts may currently be disabled globally, especially if the +hardware does not support interrupt priorities. Alternatively +interrupts may be enabled such that higher priority interrupts are +allowed through. The ISR may be running on a separate interrupt stack, +or on the stack of whichever thread was running at the time the +interrupt happened. + + +A typical ISR will do as little work as possible, just enough to meet +the needs of the hardware and then acknowledge the interrupt by +calling cyg_interrupt_acknowledge. This ensures +that interrupts will be quickly reenabled, so higher priority devices +can be serviced. For some applications there may be one device which +is especially important and whose ISR can take much longer than +normal. However eCos device drivers usually will not assume that they +are especially important, so their ISRs will be as short as possible. + + +The return value of an ISR is normally one of +CYG_ISR_CALL_DSR or +CYG_ISR_HANDLED. The former indicates that further +processing is required at DSR level, and the interrupt handler's DSR +will be run as soon as possible. The latter indicates that the +interrupt has been fully handled and no further effort is required. + + +An ISR is allowed to make very few kernel calls. It can manipulate the +interrupt mask, and on SMP systems it can use spinlocks. However an +ISR must not make higher-level kernel calls such as posting to a +semaphore, instead any such calls must be made from the DSR. This +avoids having to disable interrupts throughout the kernel and thus +improves interrupt latency. + + + + cyg_DSR_t dsr + +If an interrupt has occurred and the ISR has returned a value +CYG_ISR_CALL_DSR, the system will call the +deferred service routine or DSR associated with this interrupt +handler. If the scheduler is not currently locked then the DSR will +run immediately. However if the interrupted thread was in the middle +of a kernel call and had locked the scheduler, then the DSR will be +deferred until the scheduler is again unlocked. This allows the +DSR to make certain kernel calls safely, for example posting to a +semaphore or signalling a condition variable. A DSR is a C function +which takes the following form: + + +void +dsr_function(cyg_vector_t vector, + cyg_ucount32 count, + cyg_addrword_t data) +{ +} + + +The first argument identifies the specific interrupt that has caused +the DSR to run. The second argument indicates the number of these +interrupts that have occurred and for which the ISR requested a DSR. +Usually this will be 1, unless the system is +suffering from a very heavy load. The third argument is the +data field passed to +cyg_interrupt_create. + + + + cyg_handle_t* handle + +The kernel will return a handle to the newly created interrupt handler +via this argument. Subsequent operations on the interrupt handler such +as attaching it to the interrupt source will use this handle. + + + + cyg_interrupt* intr + +This provides the kernel with an area of memory for holding this +interrupt handler and associated data. + + + + +The call to cyg_interrupt_create simply fills in +a kernel data structure. A typical next step is to call +cyg_interrupt_attach using the handle returned by +the create operation. This makes it possible to have several different +interrupt handlers for a given vector, attaching whichever one is +currently appropriate. Replacing an interrupt handler requires a call +to cyg_interrupt_detach, followed by another call +to cyg_interrupt_attach for the replacement +handler. cyg_interrupt_delete can be used if an +interrupt handler is no longer required. + + +Some hardware may allow for further control over specific interrupts, +for example whether an interrupt is level or edge triggered. Any such +hardware functionality can be accessed using +cyg_interrupt_configure: the +level argument selects between level versus +edge triggered; the up argument selects between +high and low level, or between rising and falling edges. + + +Usually interrupt handlers are created, attached and configured during +system initialization, while global interrupts are still disabled. On +most hardware it will also be necessary to call +cyg_interrupt_unmask, since the sensible default +for interrupt masking is to ignore any interrupts for which no handler +is installed. + + + + Controlling Interrupts + +eCos provides two ways of controlling whether or not interrupts +happen. It is possible to disable and reenable all interrupts +globally, using cyg_interrupt_disable and +cyg_interrupt_enable. Typically this works by +manipulating state inside the cpu itself, for example setting a flag +in a status register or executing special instructions. Alternatively +it may be possible to mask a specific interrupt source by writing to +one or to several interrupt mask registers. Hardware-specific +documentation should be consulted for the exact details of how +interrupt masking works, because a full implementation is not possible +on all hardware. + + +The primary use for these functions is to allow data to be shared +between ISRs and other code such as DSRs or threads. If both a thread +and an ISR need to manipulate either a data structure or the hardware +itself, there is a possible conflict if an interrupt happens just when +the thread is doing such manipulation. Problems can be avoided by the +thread either disabling or masking interrupts during the critical +region. If this critical region requires only a few instructions then +usually it is more efficient to disable interrupts. For larger +critical regions it may be more appropriate to use interrupt masking, +allowing other interrupts to occur. There are other uses for interrupt +masking. For example if a device is not currently being used by the +application then it may be desirable to mask all interrupts generated +by that device. + + +There are two functions for masking a specific interrupt source, +cyg_interrupt_mask and +cyg_interrupt_mask_intunsafe. On typical hardware +masking an interrupt is not an atomic operation, so if two threads +were to perform interrupt masking operations at the same time there +could be problems. cyg_interrupt_mask disables +all interrupts while it manipulates the interrupt mask. In situations +where interrupts are already know to be disabled, +cyg_interrupt_mask_intunsafe can be used +instead. There are matching functions +cyg_interrupt_unmask and +cyg_interrupt_unmask_intsafe. + + + + SMP Support + +On SMP systems the kernel provides an additional two functions related +to interrupt handling. cyg_interrupt_set_cpu +specifies that a particular hardware interrupt should always be +handled on one specific processor in the system. In other words when +the interrupt triggers it is only that processor which detects it, and +it is only on that processor that the VSR and ISR will run. If a DSR +is requested then it will also run on the same CPU. The +function cyg_interrupt_get_cpu can be used to +find out which interrupts are handled on which processor. + + + + VSR Support + +When an interrupt occurs the hardware will transfer control to a piece +of code known as the VSR, or Vector Service Routine. By default this +code is provided by eCos. Usually it is written in assembler, but on +some architectures it may be possible to implement VSRs in C by +specifying an interrupt attribute. Compiler documentation should be +consulted for more information on this. The default eCos VSR will work +out which ISR function should process the interrupt, and set up a C +environment suitable for this ISR. + + +For some applications it may be desirable to replace the default eCos +VSR and handle some interrupts directly. This minimizes interrupt +latency, but it requires application developers to program at a lower +level. Usually the best way to write a custom VSR is to copy the +existing one supplied by eCos and then make appropriate modifications. +The function cyg_interrupt_get_vsr can be used to +get hold of the current VSR for a given interrupt vector, allowing it +to be restored if the custom VSR is no longer required. +cyg_interrupt_set_vsr can be used to install a +replacement VSR. Usually the vsr argument will +correspond to an exported label in an assembler source file. + + + + Valid contexts + +In a typical configuration interrupt handlers are created and attached +during system initialization, and never detached or deleted. However +it is possible to perform these operations at thread level, if +desired. Similarly cyg_interrupt_configure, +cyg_interrupt_set_vsr, and +cyg_interrupt_set_cpu are usually called only +during system initialization, but on typical hardware may be called at +any time. cyg_interrupt_get_vsr and +cyg_interrupt_get_cpu may be called at any time. + + +The functions for enabling, disabling, masking and unmasking +interrupts can be called in any context, when appropriate. It is the +responsibility of application developers to determine when the use of +these functions is appropriate. + + + + + + + + + + + + Kernel Real-time Characterization + + + tm_basic + Measure the performance of the eCos kernel + + + + Description + +When building a real-time system, care must be taken to ensure that +the system will be able to perform properly within the constraints of +that system. One of these constraints may be how fast certain +operations can be performed. Another might be how deterministic the +overall behavior of the system is. Lastly the memory footprint (size) +and unit cost may be important. + + +One of the major problems encountered while evaluating a system will +be how to compare it with possible alternatives. Most manufacturers of +real-time systems publish performance numbers, ostensibly so that +users can compare the different offerings. However, what these numbers +mean and how they were gathered is often not clear. The values are +typically measured on a particular piece of hardware, so in order to +truly compare, one must obtain measurements for exactly the same set +of hardware that were gathered in a similar fashion. + + +Two major items need to be present in any given set of measurements. +First, the raw values for the various operations; these are typically +quite easy to measure and will be available for most systems. Second, +the determinacy of the numbers; in other words how much the value +might change depending on other factors within the system. This value +is affected by a number of factors: how long interrupts might be +masked, whether or not the function can be interrupted, even very +hardware-specific effects such as cache locality and pipeline usage. +It is very difficult to measure the determinacy of any given +operation, but that determinacy is fundamentally important to proper +overall characterization of a system. + + +In the discussion and numbers that follow, three key measurements are +provided. The first measurement is an estimate of the interrupt latency: this is the length of time from when a hardware interrupt -occurs until its Interrupt Service Routine (ISR) -is called. The second measurement is an estimate of overall interrupt -overhead: this is the length of time average interrupt processing takes, -as measured by the real-time clock interrupt (other interrupt sources -will certainly take a different amount of time, but this data cannot -be easily gathered). The third measurement consists of the timings -for the various kernel primitives. - -Methodology -Key operations in the kernel were measured by using a - simple test program which exercises the various kernel - primitive operations. A hardware timer, normally the one - used to drive the real-time clock, was used for these - measurements. In most cases this timer can be read with - quite high resolution, typically in the range of a few - microseconds. For each measurement, the operation was - repeated a number of times. Time stamps were obtained - directly before and after the operation was performed. The - data gathered for the entire set of operations was then - analyzed, generating average (mean), maximum and minimum - values. The sample variance (a measure of how close most - samples are to the mean) was also calculated. The cost of - obtaining the real-time clock timer values was also - measured, and was subtracted from all other times. -Most kernel functions can be measured separately. -In each case, a reasonable number of iterations are performed. Where -the test case involves a kernel object, for example creating a task, -each iteration is performed on a different object. There is also -a set of tests which measures the interactions between multiple -tasks and certain kernel primitives. Most functions are tested in -such a way as to determine the variations introduced by varying -numbers of objects in the system. For example, the mailbox tests -measure the cost of a 'peek' operation when the -mailbox is empty, has a single item, and has multiple items present. -In this way, any effects of the state of the object or how many -items it contains can be determined. -There are a few things to consider about these measurements. -Firstly, they are quite micro in scale and only measure the operation -in question. These measurements do not adequately describe how the +occurs until its Interrupt Service Routine (ISR) is called. The second +measurement is an estimate of overall interrupt overhead: this is the +length of time average interrupt processing takes, as measured by the +real-time clock interrupt (other interrupt sources will certainly take +a different amount of time, but this data cannot be easily gathered). +The third measurement consists of the timings for the various kernel +primitives. + + + + Methodology + +Key operations in the kernel were measured by using a simple test +program which exercises the various kernel primitive operations. A +hardware timer, normally the one used to drive the real-time clock, +was used for these measurements. In most cases this timer can be read +with quite high resolution, typically in the range of a few +microseconds. For each measurement, the operation was repeated a +number of times. Time stamps were obtained directly before and after +the operation was performed. The data gathered for the entire set of +operations was then analyzed, generating average (mean), maximum and +minimum values. The sample variance (a measure of how close most +samples are to the mean) was also calculated. The cost of obtaining +the real-time clock timer values was also measured, and was subtracted +from all other times. + + +Most kernel functions can be measured separately. In each case, a +reasonable number of iterations are performed. Where the test case +involves a kernel object, for example creating a task, each iteration +is performed on a different object. There is also a set of tests which +measures the interactions between multiple tasks and certain kernel +primitives. Most functions are tested in such a way as to determine +the variations introduced by varying numbers of objects in the system. +For example, the mailbox tests measure the cost of a 'peek' operation +when the mailbox is empty, has a single item, and has multiple items +present. In this way, any effects of the state of the object or how +many items it contains can be determined. + + +There are a few things to consider about these measurements. Firstly, +they are quite micro in scale and only measure the operation in +question. These measurements do not adequately describe how the timings would be perturbed in a real system with multiple interrupting sources. Secondly, the possible aberration incurred by the real-time clock (system heartbeat tick) is explicitly avoided. Virtually all -kernel functions have been designed to be interruptible. Thus the times -presented are typical, but best case, since any particular function -may be interrupted by the clock tick processing. This number is -explicitly calculated so that the value may be included in any deadline -calculations required by the end user. Lastly, the reported measurements -were obtained from a system built with all options at their default -values. Kernel instrumentation and asserts are also disabled for -these measurements. Any number of configuration options can change -the measured results, sometimes quite dramatically. For example, -mutexes are using priority inheritance in these measurements. The -numbers will change if the system is built with priority inheritance -on mutex variables turned off. -The final value that is measured is an estimate of interrupt -latency. This particular value is not explicitly calculated in the -test program used, but rather by instrumenting the kernel itself. -The raw number of timer ticks that elapse between the time the timer -generates an interrupt and the start of the timer ISR is kept in -the kernel. These values are printed by the test program after all -other operations have been tested. Thus this should be a reasonable -estimate of the interrupt latency over time. - - -Using these Measurements -These measurements can be used in a number of ways. The - most typical use will be to compare different real-time - kernel offerings on similar hardware, another will be to - estimate the cost of implementing a task using eCos - (applications can be examined to see what effect the kernel - operations will have on the total execution time). Another - use would be to observe how the tuning of the kernel affects - overall operation. - - -Influences on Performance -A number of factors can affect real-time performance in - a system. One of the most common factors, yet most difficult - to characterize, is the effect of device drivers and - interrupts on system timings. Different device drivers will - have differing requirements as to how long interrupts are - suppressed, for example. The eCos system has been designed - with this in mind, by separating the management of - interrupts (ISR handlers) and the processing required by the - interrupt (DSR—Deferred - Service Routine— handlers). However, since there is so - much variability here, and indeed most device drivers will - come from the end users themselves, these effects cannot be - reliably measured. Attempts have been made to measure the - overhead of the single interrupt that eCos relies on, the - real-time clock timer. This should give you a reasonable - idea of the cost of executing interrupt handling for - devices. - - -Measured Items -This section describes the various tests and the numbers presented. All tests use the C - kernel API (available by way of - cyg/kernel/kapi.h). There is a - single main thread in the system that performs the various - tests. Additional threads may be created as part of the - testing, but these are short lived and are destroyed between - tests unless otherwise noted. The terminology “lower - priority” means a priority that is less important, not - necessarily lower in numerical value. A higher priority - thread will run in preference to a lower priority thread - even though the priority value of the higher priority thread - may be numerically less than that of the lower priority - thread. - -Thread Primitives - - -Create thread - -This test measures the - cyg_thread_create() - call. Each call creates a totally new thread. The - set of threads created by this test will be reused - in the subsequent thread primitive tests. - - - -Yield thread - -This test measures the - cyg_thread_yield() - call. For this test, there are no other runnable - threads, thus the test should just measure the - overhead of trying to give up the CPU. - - - -Suspend [suspended] thread - -This test measures the - cyg_thread_suspend() - call. A thread may be suspended multiple times; each - thread is already suspended from its initial - creation, and is suspended again. - - - -Resume thread - -This test measures the - cyg_thread_resume() - call. All of the threads have a suspend count of 2, - thus this call does not make them runnable. This - test just measures the overhead of resuming a - thread. - - - -Set priority - - This test measures the - cyg_thread_set_priority() - call. Each thread, currently suspended, has its - priority set to a new value. - - - -Get priority - -This test measures the - cyg_thread_get_priority() - call. - - - -Kill [suspended] thread - -This test measures the - cyg_thread_kill() - call. Each thread in the set is killed. All threads - are known to be suspended before being killed. - - - - -Yield [no other] thread - -This test measures the - cyg_thread_yield() - call again. This is to demonstrate that the - cyg_thread_yield() - call has a fixed overhead, regardless of whether - there are other threads in the system. - - - -Resume [suspended low priority] thread - -This test measures the - cyg_thread_resume() - call again. In this case, the thread being resumed - is lower priority than the main thread, thus it will - simply become ready to run but not be granted the - CPU. This test measures the cost of making a thread - ready to run. - - - -Resume [runnable low priority] thread - -This test measures the - cyg_thread_resume() - call again. In this case, the thread being resumed - is lower priority than the main thread and has - already been made runnable, so in fact the resume - call has no effect. - - - -Suspend [runnable] thread - -This test measures the - cyg_thread_suspend() - call again. In this case, each thread has already - been made runnable (by previous tests). - - - -Yield [only low priority] thread - -This test measures the - cyg_thread_yield() - call. In this case, there are many other runnable - threads, but they are all lower priority than the - main thread, thus no thread switches will take - place. - - - -Suspend [runnable->not runnable] thread - -This test measures the - cyg_thread_suspend() - call again. The thread being suspended will become - non-runnable by this action. - - - -Kill [runnable] thread - -This test measures the - cyg_thread_kill() - call again. In this case, the thread being killed - is currently runnable, but lower priority than the - main thread. - - - -Resume [high priority] thread - -This test measures the - cyg_thread_resume() - call. The thread being resumed is higher priority - than the main thread, thus a thread switch will take - place on each call. In fact there will be two thread - switches; one to the new higher priority thread and - a second back to the test thread. The test thread - exits immediately. - - - -Thread switch - -This test attempts to measure the cost of - switching from one thread to another. Two equal - priority threads are started and they will each - yield to the other for a number of iterations. A - time stamp is gathered in one thread before the - cyg_thread_yield() - call and after the call in the other thread. - - - - - -Scheduler Primitives - - -Scheduler lock - -This test measures the - cyg_scheduler_lock() - call. - - - -Scheduler unlock [0 threads] - -This test measures the - cyg_scheduler_unlock() - call. There are no other threads in the system and - the unlock happens immediately after a lock so there - will be no pending DSR’s to run. - - - -Scheduler unlock [1 suspended thread] - -This test measures the cyg_scheduler_unlock() call. -There is one other thread in the system which is currently suspended. - - - -Scheduler unlock [many suspended threads] - -This test measures the cyg_scheduler_unlock() call. -There are many other threads in the system which are currently suspended. The -purpose of this test is to determine the cost of having additional -threads in the system when the scheduler is activated by way of - cyg_scheduler_unlock(). - - - -Scheduler unlock [many low priority threads] - -This test measures the cyg_scheduler_unlock() call. -There are many other threads in the system which are runnable but -are lower priority than the main thread. The purpose of this test +kernel functions have been designed to be interruptible. Thus the +times presented are typical, but best case, since any particular +function may be interrupted by the clock tick processing. This number +is explicitly calculated so that the value may be included in any +deadline calculations required by the end user. Lastly, the reported +measurements were obtained from a system built with all options at +their default values. Kernel instrumentation and asserts are also +disabled for these measurements. Any number of configuration options +can change the measured results, sometimes quite dramatically. For +example, mutexes are using priority inheritance in these measurements. +The numbers will change if the system is built with priority +inheritance on mutex variables turned off. + + +The final value that is measured is an estimate of interrupt latency. +This particular value is not explicitly calculated in the test program +used, but rather by instrumenting the kernel itself. The raw number of +timer ticks that elapse between the time the timer generates an +interrupt and the start of the timer ISR is kept in the kernel. These +values are printed by the test program after all other operations have +been tested. Thus this should be a reasonable estimate of the +interrupt latency over time. + + + + + Using these Measurements + +These measurements can be used in a number of ways. The most typical +use will be to compare different real-time kernel offerings on similar +hardware, another will be to estimate the cost of implementing a task +using eCos (applications can be examined to see what effect the kernel +operations will have on the total execution time). Another use would +be to observe how the tuning of the kernel affects overall operation. + + + + + Influences on Performance + +A number of factors can affect real-time performance in a system. One +of the most common factors, yet most difficult to characterize, is the +effect of device drivers and interrupts on system timings. Different +device drivers will have differing requirements as to how long +interrupts are suppressed, for example. The eCos system has been +designed with this in mind, by separating the management of interrupts +(ISR handlers) and the processing required by the interrupt +(DSR—Deferred Service Routine— handlers). However, since +there is so much variability here, and indeed most device drivers will +come from the end users themselves, these effects cannot be reliably +measured. Attempts have been made to measure the overhead of the +single interrupt that eCos relies on, the real-time clock timer. This +should give you a reasonable idea of the cost of executing interrupt +handling for devices. + + + + + Measured Items + +This section describes the various tests and the numbers presented. +All tests use the C kernel API (available by way of +cyg/kernel/kapi.h). There is a single main thread +in the system that performs the various tests. Additional threads may +be created as part of the testing, but these are short lived and are +destroyed between tests unless otherwise noted. The terminology +“lower priority” means a priority that is less important, +not necessarily lower in numerical value. A higher priority thread +will run in preference to a lower priority thread even though the +priority value of the higher priority thread may be numerically less +than that of the lower priority thread. + + + + Thread Primitives + + + Create thread + +This test measures the cyg_thread_create() call. +Each call creates a totally new thread. The set of threads created by +this test will be reused in the subsequent thread primitive tests. + + + + Yield thread + +This test measures the cyg_thread_yield() call. +For this test, there are no other runnable threads, thus the test +should just measure the overhead of trying to give up the CPU. + + + + Suspend [suspended] thread + +This test measures the cyg_thread_suspend() call. +A thread may be suspended multiple times; each thread is already +suspended from its initial creation, and is suspended again. + + + + Resume thread + +This test measures the cyg_thread_resume() call. +All of the threads have a suspend count of 2, thus this call does not +make them runnable. This test just measures the overhead of resuming a +thread. + + + + Set priority + +This test measures the cyg_thread_set_priority() +call. Each thread, currently suspended, has its priority set to a new +value. + + + + Get priority + +This test measures the cyg_thread_get_priority() +call. + + + + Kill [suspended] thread + +This test measures the cyg_thread_kill() call. +Each thread in the set is killed. All threads are known to be +suspended before being killed. + + + + Yield [no other] thread + +This test measures the cyg_thread_yield() call +again. This is to demonstrate that the +cyg_thread_yield() call has a fixed overhead, +regardless of whether there are other threads in the system. + + + + Resume [suspended low priority] thread + +This test measures the cyg_thread_resume() call +again. In this case, the thread being resumed is lower priority than +the main thread, thus it will simply become ready to run but not be +granted the CPU. This test measures the cost of making a thread ready +to run. + + + + Resume [runnable low priority] thread + +This test measures the cyg_thread_resume() call +again. In this case, the thread being resumed is lower priority than +the main thread and has already been made runnable, so in fact the +resume call has no effect. + + + + Suspend [runnable] thread + +This test measures the cyg_thread_suspend() call +again. In this case, each thread has already been made runnable (by +previous tests). + + + + Yield [only low priority] thread + +This test measures the cyg_thread_yield() call. +In this case, there are many other runnable threads, but they are all +lower priority than the main thread, thus no thread switches will take +place. + + + + Suspend [runnable->not runnable] thread + +This test measures the cyg_thread_suspend() call +again. The thread being suspended will become non-runnable by this +action. + + + + Kill [runnable] thread + +This test measures the cyg_thread_kill() call +again. In this case, the thread being killed is currently runnable, +but lower priority than the main thread. + + + + Resume [high priority] thread + +This test measures the cyg_thread_resume() call. +The thread being resumed is higher priority than the main thread, thus +a thread switch will take place on each call. In fact there will be +two thread switches; one to the new higher priority thread and a +second back to the test thread. The test thread exits immediately. + + + + Thread switch + +This test attempts to measure the cost of switching from one thread to +another. Two equal priority threads are started and they will each +yield to the other for a number of iterations. A time stamp is +gathered in one thread before the +cyg_thread_yield() call and after the call in the +other thread. + + + + + + Scheduler Primitives + + + Scheduler lock + +This test measures the cyg_scheduler_lock() call. + + + + Scheduler unlock [0 threads] + +This test measures the cyg_scheduler_unlock() +call. There are no other threads in the system and the unlock happens +immediately after a lock so there will be no pending DSR’s to +run. + + + + Scheduler unlock [1 suspended thread] + +This test measures the cyg_scheduler_unlock() +call. There is one other thread in the system which is currently +suspended. + + + + Scheduler unlock [many suspended threads] + +This test measures the cyg_scheduler_unlock() +call. There are many other threads in the system which are currently +suspended. The purpose of this test is to determine the cost of having +additional threads in the system when the scheduler is activated by +way of cyg_scheduler_unlock(). + + + + Scheduler unlock [many low priority threads] + +This test measures the cyg_scheduler_unlock() +call. There are many other threads in the system which are runnable +but are lower priority than the main thread. The purpose of this test is to determine the cost of having additional threads in the system -when the scheduler is activated by way of cyg_scheduler_unlock(). - - - - - -Mutex Primitives - - -Init mutex - -This test measures the cyg_mutex_init() call. -A number of separate mutex variables are created. The purpose of -this test is to measure the cost of creating a new mutex and introducing -it to the system. - - - -Lock [unlocked] mutex - -This test measures the cyg_mutex_lock() call. +when the scheduler is activated by way of +cyg_scheduler_unlock(). + + + + + + + Mutex Primitives + + + Init mutex + +This test measures the cyg_mutex_init() call. A +number of separate mutex variables are created. The purpose of this +test is to measure the cost of creating a new mutex and introducing it +to the system. + + + + Lock [unlocked] mutex + +This test measures the cyg_mutex_lock() call. The +purpose of this test is to measure the cost of locking a mutex which +is currently unlocked. There are no other threads executing in the +system while this test runs. + + + + Unlock [locked] mutex + +This test measures the cyg_mutex_unlock() call. +The purpose of this test is to measure the cost of unlocking a mutex +which is currently locked. There are no other threads executing in the +system while this test runs. + + + + Trylock [unlocked] mutex + +This test measures the cyg_mutex_trylock() call. The purpose of this test is to measure the cost of locking a mutex -which is currently unlocked. There are no other threads executing -in the system while this test runs. - - - -Unlock [locked] mutex - -This test measures the cyg_mutex_unlock() call. -The purpose of this test is to measure the cost of unlocking a mutex -which is currently locked. There are no other threads executing -in the system while this test runs. - - - -Trylock [unlocked] mutex - -This test measures the cyg_mutex_trylock() call. +which is currently unlocked. There are no other threads executing in +the system while this test runs. + + + + Trylock [locked] mutex + +This test measures the cyg_mutex_trylock() call. The purpose of this test is to measure the cost of locking a mutex -which is currently unlocked. There are no other threads executing -in the system while this test runs. - - - -Trylock [locked] mutex - -This test measures the cyg_mutex_trylock() call. -The purpose of this test is to measure the cost of locking a mutex -which is currently locked. There are no other threads executing -in the system while this test runs. - - - -Destroy mutex - -This test measures the cyg_mutex_destroy() call. +which is currently locked. There are no other threads executing in the +system while this test runs. + + + + Destroy mutex + +This test measures the cyg_mutex_destroy() call. The purpose of this test is to measure the cost of deleting a mutex from the system. There are no other threads executing in the system -while this test runs. - - - -Unlock/Lock mutex - -This test attempts to measure the cost of unlocking a mutex -for which there is another higher priority thread waiting. When -the mutex is unlocked, the higher priority waiting thread will immediately -take the lock. The time from when the unlock is issued until after -the lock succeeds in the second thread is measured, thus giving -the round-trip or circuit time for this type of synchronizer. - - - - - -Mailbox Primitives - - -Create mbox - -This test measures the cyg_mbox_create() call. -A number of separate mailboxes is created. The purpose of this test -is to measure the cost of creating a new mailbox and introducing -it to the system. - - - -Peek [empty] mbox - -This test measures the cyg_mbox_peek() call. -An attempt is made to peek the value in each mailbox, which is currently empty. -The purpose of this test is to measure the cost of checking a mailbox -for a value without blocking. - - - -Put [first] mbox - -This test measures the cyg_mbox_put() call. -One item is added to a currently empty mailbox. The purpose of this -test is to measure the cost of adding an item to a mailbox. There -are no other threads currently waiting for mailbox items to - arrive. - - - -Peek [1 msg] mbox - -This test measures the cyg_mbox_peek() call. -An attempt is made to peek the value in each mailbox, which contains -a single item. The purpose of this test is to measure the cost of -checking a mailbox which has data to deliver. - - - -Put [second] mbox - -This test measures the cyg_mbox_put() call. -A second item is added to a mailbox. The purpose of this test is -to measure the cost of adding an additional item to a mailbox. There -are no other threads currently waiting for mailbox items to - arrive. - - - -Peek [2 msgs] mbox - -This test measures the cyg_mbox_peek() call. -An attempt is made to peek the value in each mailbox, which contains -two items. The purpose of this test is to measure the cost of checking -a mailbox which has data to deliver. - - - -Get [first] mbox - -This test measures the cyg_mbox_get() call. -The first item is removed from a mailbox that currently contains -two items. The purpose of this test is to measure the cost of obtaining -an item from a mailbox without blocking. - - - -Get [second] mbox - -This test measures the cyg_mbox_get() call. -The last item is removed from a mailbox that currently contains -one item. The purpose of this test is to measure the cost of obtaining -an item from a mailbox without blocking. - - - -Tryput [first] mbox - -This test measures the cyg_mbox_tryput() call. -A single item is added to a currently empty mailbox. The purpose -of this test is to measure the cost of adding an item to a - mailbox. - - - -Peek item [non-empty] mbox - -This test measures the cyg_mbox_peek_item() call. +while this test runs. + + + + Unlock/Lock mutex + +This test attempts to measure the cost of unlocking a mutex for which +there is another higher priority thread waiting. When the mutex is +unlocked, the higher priority waiting thread will immediately take the +lock. The time from when the unlock is issued until after the lock +succeeds in the second thread is measured, thus giving the round-trip +or circuit time for this type of synchronizer. + + + + + + + Mailbox Primitives + + + Create mbox + +This test measures the cyg_mbox_create() call. A +number of separate mailboxes is created. The purpose of this test is +to measure the cost of creating a new mailbox and introducing it to +the system. + + + + Peek [empty] mbox + +This test measures the cyg_mbox_peek() call. An +attempt is made to peek the value in each mailbox, which is currently +empty. The purpose of this test is to measure the cost of checking a +mailbox for a value without blocking. + + + + Put [first] mbox + +This test measures the cyg_mbox_put() call. One +item is added to a currently empty mailbox. The purpose of this test +is to measure the cost of adding an item to a mailbox. There are no +other threads currently waiting for mailbox items to arrive. + + + + Peek [1 msg] mbox + +This test measures the cyg_mbox_peek() call. An +attempt is made to peek the value in each mailbox, which contains a +single item. The purpose of this test is to measure the cost of +checking a mailbox which has data to deliver. + + + + Put [second] mbox + +This test measures the cyg_mbox_put() call. A +second item is added to a mailbox. The purpose of this test is to +measure the cost of adding an additional item to a mailbox. There are +no other threads currently waiting for mailbox items to arrive. + + + + Peek [2 msgs] mbox + +This test measures the cyg_mbox_peek() call. An +attempt is made to peek the value in each mailbox, which contains two +items. The purpose of this test is to measure the cost of checking a +mailbox which has data to deliver. + + + + Get [first] mbox + +This test measures the cyg_mbox_get() call. The +first item is removed from a mailbox that currently contains two +items. The purpose of this test is to measure the cost of obtaining an +item from a mailbox without blocking. + + + + Get [second] mbox + +This test measures the cyg_mbox_get() call. The +last item is removed from a mailbox that currently contains one item. +The purpose of this test is to measure the cost of obtaining an item +from a mailbox without blocking. + + + + Tryput [first] mbox + +This test measures the cyg_mbox_tryput() call. A +single item is added to a currently empty mailbox. The purpose of this +test is to measure the cost of adding an item to a mailbox. + + + + Peek item [non-empty] mbox + +This test measures the cyg_mbox_peek_item() call. A single item is fetched from a mailbox that contains a single item. -The purpose of this test is to measure the cost of obtaining an -item without disturbing the mailbox. - - - -Tryget [non-empty] mbox - -This test measures the cyg_mbox_tryget() call. -A single item is removed from a mailbox that contains exactly one -item. The purpose of this test is to measure the cost of obtaining -one item from a non-empty mailbox. - - - -Peek item [empty] mbox - -This test measures the cyg_mbox_peek_item() call. -An attempt is made to fetch an item from a mailbox that is empty. -The purpose of this test is to measure the cost of trying to obtain -an item when the mailbox is empty. - - - -Tryget [empty] mbox - -This test measures the cyg_mbox_tryget() call. -An attempt is made to fetch an item from a mailbox that is empty. -The purpose of this test is to measure the cost of trying to obtain -an item when the mailbox is empty. - - - -Waiting to get mbox - -This test measures the cyg_mbox_waiting_to_get() call. -The purpose of this test is to measure the cost of determining how -many threads are waiting to obtain a message from this - mailbox. - - - -Waiting to put mbox - -This test measures the cyg_mbox_waiting_to_put() call. -The purpose of this test is to measure the cost of determining how -many threads are waiting to put a message into this mailbox. - - - -Delete mbox - -This test measures the cyg_mbox_delete() call. +The purpose of this test is to measure the cost of obtaining an item +without disturbing the mailbox. + + + + Tryget [non-empty] mbox + +This test measures the cyg_mbox_tryget() call. A +single item is removed from a mailbox that contains exactly one item. +The purpose of this test is to measure the cost of obtaining one item +from a non-empty mailbox. + + + + Peek item [empty] mbox + +This test measures the cyg_mbox_peek_item() call. +An attempt is made to fetch an item from a mailbox that is empty. The +purpose of this test is to measure the cost of trying to obtain an +item when the mailbox is empty. + + + + Tryget [empty] mbox + +This test measures the cyg_mbox_tryget() call. An +attempt is made to fetch an item from a mailbox that is empty. The +purpose of this test is to measure the cost of trying to obtain an +item when the mailbox is empty. + + + + Waiting to get mbox + +This test measures the cyg_mbox_waiting_to_get() +call. The purpose of this test is to measure the cost of determining +how many threads are waiting to obtain a message from this mailbox. + + + + Waiting to put mbox + +This test measures the cyg_mbox_waiting_to_put() +call. The purpose of this test is to measure the cost of determining +how many threads are waiting to put a message into this mailbox. + + + + Delete mbox + +This test measures the cyg_mbox_delete() call. The purpose of this test is to measure the cost of destroying a -mailbox and removing it from the system. - - - -Put/Get mbox - -In this round-trip test, one thread is sending data to a mailbox -that is being consumed by another thread. The time from when the -data is put into the mailbox until it has been delivered to the -waiting thread is measured. Note that this time will contain a thread -switch. - - - - - -Semaphore Primitives - - -Init semaphore - -This test measures the cyg_semaphore_init() call. -A number of separate semaphore objects are created and introduced -to the system. The purpose of this test is to measure the cost of -creating a new semaphore. - - - -Post [0] semaphore - -This test measures the cyg_semaphore_post() call. +mailbox and removing it from the system. + + + + Put/Get mbox + +In this round-trip test, one thread is sending data to a mailbox that +is being consumed by another thread. The time from when the data is +put into the mailbox until it has been delivered to the waiting thread +is measured. Note that this time will contain a thread switch. + + + + + + + Semaphore Primitives + + + Init semaphore + +This test measures the cyg_semaphore_init() call. +A number of separate semaphore objects are created and introduced to +the system. The purpose of this test is to measure the cost of +creating a new semaphore. + + + + Post [0] semaphore + +This test measures the cyg_semaphore_post() call. Each semaphore currently has a value of 0 and there are no other threads in the system. The purpose of this test is to measure the overhead cost of posting to a semaphore. This cost will differ if -there is a thread waiting for the semaphore. - - - -Wait [1] semaphore - -This test measures the cyg_semaphore_wait() call. +there is a thread waiting for the semaphore. + + + + Wait [1] semaphore + +This test measures the cyg_semaphore_wait() call. The semaphore has a current value of 1 so the call is non-blocking. -The purpose of the test is to measure the overhead of “taking” a -semaphore. - - - -Trywait [0] semaphore - -This test measures the cyg_semaphore_trywait() call. -The semaphore has a value of 0 when the call is made. The purpose -of this test is to measure the cost of seeing if a semaphore can -be “taken” without blocking. In this case, the -answer would be no. - - - -Trywait [1] semaphore - -This test measures the cyg_semaphore_trywait() call. -The semaphore has a value of 1 when the call is made. The purpose -of this test is to measure the cost of seeing if a semaphore can -be “taken” without blocking. In this case, the -answer would be yes. - - - -Peek semaphore - -This test measures the cyg_semaphore_peek() call. +The purpose of the test is to measure the overhead of +“taking” a semaphore. + + + + Trywait [0] semaphore + +This test measures the cyg_semaphore_trywait() +call. The semaphore has a value of 0 when the call is made. The +purpose of this test is to measure the cost of seeing if a semaphore +can be “taken” without blocking. In this case, the answer +would be no. + + + + Trywait [1] semaphore + +This test measures the cyg_semaphore_trywait() +call. The semaphore has a value of 1 when the call is made. The +purpose of this test is to measure the cost of seeing if a semaphore +can be “taken” without blocking. In this case, the answer +would be yes. + + + + Peek semaphore + +This test measures the cyg_semaphore_peek() call. The purpose of this test is to measure the cost of obtaining the -current semaphore count value. - - - -Destroy semaphore - -This test measures the cyg_semaphore_destroy() call. -The purpose of this test is to measure the cost of deleting a semaphore -from the system. - - - -Post/Wait semaphore - -In this round-trip test, two threads are passing control back -and forth by using a semaphore. The time from when one thread calls cyg_semaphore_post() until -the other thread completes its cyg_semaphore_wait() is -measured. Note that each iteration of this test will involve a thread -switch. - - - - - -Counters - - -Create counter - -This test measures the cyg_counter_create() call. -A number of separate counters are created. The purpose of this test -is to measure the cost of creating a new counter and introducing -it to the system. - - - -Get counter value - -This test measures the cyg_counter_current_value() call. -The current value of each counter is obtained. - - - -Set counter value - -This test measures the cyg_counter_set_value() call. -Each counter is set to a new value. - - - -Tick counter - -This test measures the cyg_counter_tick() call. -Each counter is “ticked” once. - - - -Delete counter - -This test measures the cyg_counter_delete() call. -Each counter is deleted from the system. The purpose of this test -is to measure the cost of deleting a counter object. - - - - - -Alarms - - -Create alarm - -This test measures the cyg_alarm_create() call. -A number of separate alarms are created, all attached to the same -counter object. The purpose of this test is to measure the cost -of creating a new counter and introducing it to the system. - - - -Initialize alarm - -This test measures the cyg_alarm_initialize() call. -Each alarm is initialized to a small value. - - - -Disable alarm - -This test measures the cyg_alarm_disable() call. -Each alarm is explicitly disabled. - - - -Enable alarm - -This test measures the cyg_alarm_enable() call. -Each alarm is explicitly enabled. - - - -Delete alarm - -This test measures the cyg_alarm_delete() call. -Each alarm is destroyed. The purpose of this test is to measure -the cost of deleting an alarm and removing it from the system. - - - -Tick counter [1 alarm] - -This test measures the cyg_counter_tick() call. -A counter is created that has a single alarm attached to it. The +current semaphore count value. + + + + Destroy semaphore + +This test measures the cyg_semaphore_destroy() +call. The purpose of this test is to measure the cost of deleting a +semaphore from the system. + + + + Post/Wait semaphore + +In this round-trip test, two threads are passing control back and +forth by using a semaphore. The time from when one thread calls +cyg_semaphore_post() until the other thread +completes its cyg_semaphore_wait() is measured. +Note that each iteration of this test will involve a thread switch. + + + + + + + Counters + + + Create counter + +This test measures the cyg_counter_create() call. +A number of separate counters are created. The purpose of this test is +to measure the cost of creating a new counter and introducing it to +the system. + + + + Get counter value + +This test measures the +cyg_counter_current_value() call. The current +value of each counter is obtained. + + + + Set counter value + +This test measures the cyg_counter_set_value() +call. Each counter is set to a new value. + + + + Tick counter + +This test measures the cyg_counter_tick() call. +Each counter is “ticked” once. + + + + Delete counter + +This test measures the cyg_counter_delete() call. +Each counter is deleted from the system. The purpose of this test is +to measure the cost of deleting a counter object. + + + + + + + Alarms + + + Create alarm + +This test measures the cyg_alarm_create() call. A +number of separate alarms are created, all attached to the same +counter object. The purpose of this test is to measure the cost of +creating a new counter and introducing it to the system. + + + + Initialize alarm + +This test measures the cyg_alarm_initialize() +call. Each alarm is initialized to a small value. + + + + Disable alarm + +This test measures the cyg_alarm_disable() call. +Each alarm is explicitly disabled. + + + + Enable alarm + +This test measures the cyg_alarm_enable() call. +Each alarm is explicitly enabled. + + + + Delete alarm + +This test measures the cyg_alarm_delete() call. +Each alarm is destroyed. The purpose of this test is to measure the +cost of deleting an alarm and removing it from the system. + + + + Tick counter [1 alarm] + +This test measures the cyg_counter_tick() call. A +counter is created that has a single alarm attached to it. The purpose +of this test is to measure the cost of “ticking” a counter +when it has a single attached alarm. In this test, the alarm is not +activated (fired). + + + + Tick counter [many alarms] + +This test measures the cyg_counter_tick() call. A +counter is created that has multiple alarms attached to it. The purpose of this test is to measure the cost of “ticking” a -counter when it has a single attached alarm. In this test, the alarm -is not activated (fired). - - - -Tick counter [many alarms] - -This test measures the cyg_counter_tick() call. -A counter is created that has multiple alarms attached to it. The -purpose of this test is to measure the cost of “ticking” a -counter when it has many attached alarms. In this test, the alarms -are not activated (fired). - - - -Tick & fire counter [1 alarm] - -This test measures the cyg_counter_tick() call. -A counter is created that has a single alarm attached to it. The -purpose of this test is to measure the cost of “ticking” a -counter when it has a single attached alarm. In this test, the alarm -is activated (fired). Thus the measured time will include the overhead -of calling the alarm callback function. - - - -Tick & fire counter [many alarms] - -This test measures the cyg_counter_tick() call. -A counter is created that has multiple alarms attached to it. The +counter when it has many attached alarms. In this test, the alarms are +not activated (fired). + + + + Tick & fire counter [1 alarm] + +This test measures the cyg_counter_tick() call. A +counter is created that has a single alarm attached to it. The purpose +of this test is to measure the cost of “ticking” a counter +when it has a single attached alarm. In this test, the alarm is +activated (fired). Thus the measured time will include the overhead of +calling the alarm callback function. + + + + Tick & fire counter [many alarms] + +This test measures the cyg_counter_tick() call. A +counter is created that has multiple alarms attached to it. The purpose of this test is to measure the cost of “ticking” a -counter when it has many attached alarms. In this test, the alarms -are activated (fired). Thus the measured time will include the overhead -of calling the alarm callback function. - - - -Alarm latency [0 threads] - -This test attempts to measure the latency in calling an alarm -callback function. The time from the clock interrupt until the alarm -function is called is measured. In this test, there are no threads -that can be run, other than the system idle thread, when the clock -interrupt occurs (all threads are suspended). - - - -Alarm latency [2 threads] - -This test attempts to measure the latency in calling an alarm -callback function. The time from the clock interrupt until the alarm -function is called is measured. In this test, there are exactly -two threads which are running when the clock interrupt occurs. They -are simply passing back and forth by way of the cyg_thread_yield() call. -The purpose of this test is to measure the variations in the latency -when there are executing threads. - - - -Alarm latency [many threads] - -This test attempts to measure the - latency in calling an alarm callback function. The - time from the clock interrupt until the alarm - function is called is measured. In this test, there - are a number of threads which are running when the - clock interrupt occurs. They are simply passing back - and forth by way of the - cyg_thread_yield() - call. The purpose of this test is to measure the - variations in the latency when there are many - executing threads. - - - - - - -Sample Numbers -For sample results, see Appendix 1 of Getting - Started with eCos - - +counter when it has many attached alarms. In this test, the alarms are +activated (fired). Thus the measured time will include the overhead of +calling the alarm callback function. + + + + Alarm latency [0 threads] + +This test attempts to measure the latency in calling an alarm callback +function. The time from the clock interrupt until the alarm function +is called is measured. In this test, there are no threads that can be +run, other than the system idle thread, when the clock interrupt +occurs (all threads are suspended). + + + + Alarm latency [2 threads] + +This test attempts to measure the latency in calling an alarm callback +function. The time from the clock interrupt until the alarm function +is called is measured. In this test, there are exactly two threads +which are running when the clock interrupt occurs. They are simply +passing back and forth by way of the +cyg_thread_yield() call. The purpose of this test +is to measure the variations in the latency when there are executing +threads. + + + + Alarm latency [many threads] + +This test attempts to measure the latency in calling an alarm callback +function. The time from the clock interrupt until the alarm function +is called is measured. In this test, there are a number of threads +which are running when the clock interrupt occurs. They are simply +passing back and forth by way of the +cyg_thread_yield() call. The purpose of this test +is to measure the variations in the latency when there are many +executing threads. + + + + + + + + + + + diff --git a/packages/kernel/current/include/bitmap.hxx b/packages/kernel/current/include/bitmap.hxx --- a/packages/kernel/current/include/bitmap.hxx +++ b/packages/kernel/current/include/bitmap.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/clock.hxx b/packages/kernel/current/include/clock.hxx --- a/packages/kernel/current/include/clock.hxx +++ b/packages/kernel/current/include/clock.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/clock.inl b/packages/kernel/current/include/clock.inl --- a/packages/kernel/current/include/clock.inl +++ b/packages/kernel/current/include/clock.inl @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/diag.h b/packages/kernel/current/include/diag.h --- a/packages/kernel/current/include/diag.h +++ b/packages/kernel/current/include/diag.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/errors.h b/packages/kernel/current/include/errors.h --- a/packages/kernel/current/include/errors.h +++ b/packages/kernel/current/include/errors.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/except.hxx b/packages/kernel/current/include/except.hxx --- a/packages/kernel/current/include/except.hxx +++ b/packages/kernel/current/include/except.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/flag.hxx b/packages/kernel/current/include/flag.hxx --- a/packages/kernel/current/include/flag.hxx +++ b/packages/kernel/current/include/flag.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/instrmnt.h b/packages/kernel/current/include/instrmnt.h --- a/packages/kernel/current/include/instrmnt.h +++ b/packages/kernel/current/include/instrmnt.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/intr.hxx b/packages/kernel/current/include/intr.hxx --- a/packages/kernel/current/include/intr.hxx +++ b/packages/kernel/current/include/intr.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/kapi.h b/packages/kernel/current/include/kapi.h --- a/packages/kernel/current/include/kapi.h +++ b/packages/kernel/current/include/kapi.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -222,6 +222,19 @@ void cyg_thread_set_data(cyg_ucount32 in #endif /*---------------------------------------------------------------------------*/ +/* Thread destructors */ + +#ifdef CYGPKG_KERNEL_THREADS_DESTRUCTORS + +typedef void (*cyg_thread_destructor_fn)(cyg_addrword_t); + +cyg_bool_t cyg_thread_add_destructor( cyg_thread_destructor_fn fn, + cyg_addrword_t data ); +cyg_bool_t cyg_thread_rem_destructor( cyg_thread_destructor_fn fn, + cyg_addrword_t data ); +#endif + +/*---------------------------------------------------------------------------*/ /* Exception handling. */ /* Replace current exception handler, this may apply to either the */ diff --git a/packages/kernel/current/include/kapidata.h b/packages/kernel/current/include/kapidata.h --- a/packages/kernel/current/include/kapidata.h +++ b/packages/kernel/current/include/kapidata.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -400,11 +400,9 @@ typedef enum #ifdef CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD -typedef void (*cyg_thread_destructor_fn)(CYG_ADDRWORD); - struct Cyg_Destructor_Entry { cyg_thread_destructor_fn fn; - CYG_ADDRWORD data; + cyg_addrword_t data; }; # define CYG_THREAD_DESTRUCTORS_MEMBER \ struct Cyg_Destructor_Entry destructors[ CYGNUM_KERNEL_THREADS_DESTRUCTORS ]; diff --git a/packages/kernel/current/include/kernel.hxx b/packages/kernel/current/include/kernel.hxx --- a/packages/kernel/current/include/kernel.hxx +++ b/packages/kernel/current/include/kernel.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/ktypes.h b/packages/kernel/current/include/ktypes.h --- a/packages/kernel/current/include/ktypes.h +++ b/packages/kernel/current/include/ktypes.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/llistt.hxx b/packages/kernel/current/include/llistt.hxx --- a/packages/kernel/current/include/llistt.hxx +++ b/packages/kernel/current/include/llistt.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/lottery.hxx b/packages/kernel/current/include/lottery.hxx --- a/packages/kernel/current/include/lottery.hxx +++ b/packages/kernel/current/include/lottery.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mbox.hxx b/packages/kernel/current/include/mbox.hxx --- a/packages/kernel/current/include/mbox.hxx +++ b/packages/kernel/current/include/mbox.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mboxt.hxx b/packages/kernel/current/include/mboxt.hxx --- a/packages/kernel/current/include/mboxt.hxx +++ b/packages/kernel/current/include/mboxt.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mboxt.inl b/packages/kernel/current/include/mboxt.inl --- a/packages/kernel/current/include/mboxt.inl +++ b/packages/kernel/current/include/mboxt.inl @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mboxt2.hxx b/packages/kernel/current/include/mboxt2.hxx --- a/packages/kernel/current/include/mboxt2.hxx +++ b/packages/kernel/current/include/mboxt2.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mboxt2.inl b/packages/kernel/current/include/mboxt2.inl --- a/packages/kernel/current/include/mboxt2.inl +++ b/packages/kernel/current/include/mboxt2.inl @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mlqueue.hxx b/packages/kernel/current/include/mlqueue.hxx --- a/packages/kernel/current/include/mlqueue.hxx +++ b/packages/kernel/current/include/mlqueue.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/mqueue.hxx b/packages/kernel/current/include/mqueue.hxx --- a/packages/kernel/current/include/mqueue.hxx +++ b/packages/kernel/current/include/mqueue.hxx @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/kernel/current/include/mqueue.inl b/packages/kernel/current/include/mqueue.inl --- a/packages/kernel/current/include/mqueue.inl +++ b/packages/kernel/current/include/mqueue.inl @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/kernel/current/include/mutex.hxx b/packages/kernel/current/include/mutex.hxx --- a/packages/kernel/current/include/mutex.hxx +++ b/packages/kernel/current/include/mutex.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/sched.hxx b/packages/kernel/current/include/sched.hxx --- a/packages/kernel/current/include/sched.hxx +++ b/packages/kernel/current/include/sched.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/sched.inl b/packages/kernel/current/include/sched.inl --- a/packages/kernel/current/include/sched.inl +++ b/packages/kernel/current/include/sched.inl @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/sema.hxx b/packages/kernel/current/include/sema.hxx --- a/packages/kernel/current/include/sema.hxx +++ b/packages/kernel/current/include/sema.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/sema2.hxx b/packages/kernel/current/include/sema2.hxx --- a/packages/kernel/current/include/sema2.hxx +++ b/packages/kernel/current/include/sema2.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/smp.hxx b/packages/kernel/current/include/smp.hxx --- a/packages/kernel/current/include/smp.hxx +++ b/packages/kernel/current/include/smp.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/test/stackmon.h b/packages/kernel/current/include/test/stackmon.h --- a/packages/kernel/current/include/test/stackmon.h +++ b/packages/kernel/current/include/test/stackmon.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/include/thread.hxx b/packages/kernel/current/include/thread.hxx --- a/packages/kernel/current/include/thread.hxx +++ b/packages/kernel/current/include/thread.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -467,8 +467,14 @@ private: public: // Add and remove destructors. Returns true on success, false on failure. - static cyg_bool add_destructor( destructor_fn fn, CYG_ADDRWORD data ); - static cyg_bool rem_destructor( destructor_fn fn, CYG_ADDRWORD data ); +#ifndef CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD + static +#endif + cyg_bool add_destructor( destructor_fn fn, CYG_ADDRWORD data ); +#ifndef CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD + static +#endif + cyg_bool rem_destructor( destructor_fn fn, CYG_ADDRWORD data ); #endif #ifdef CYGVAR_KERNEL_THREADS_NAME diff --git a/packages/kernel/current/include/thread.inl b/packages/kernel/current/include/thread.inl --- a/packages/kernel/current/include/thread.inl +++ b/packages/kernel/current/include/thread.inl @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -504,21 +504,27 @@ inline void Cyg_Thread::set_data( Cyg_Th #ifdef CYGPKG_KERNEL_THREADS_DESTRUCTORS - // Add and remove destructors. Returns true on success, false on failure. +// Add and remove destructors. Returns true on success, false on failure. inline cyg_bool Cyg_Thread::add_destructor( destructor_fn fn, CYG_ADDRWORD data ) { cyg_ucount16 i; +#ifndef CYGSEM_KERNEL_THREADS_DESTRUCTORS_PER_THREAD Cyg_Scheduler::lock(); +#endif for (i=0; iadd_destructor( fn, data ); +} + +__externC cyg_bool_t +cyg_thread_rem_destructor( cyg_thread_destructor_fn fn, + cyg_addrword_t data ) +{ + return Cyg_Thread::self()->rem_destructor( fn, data ); +} +#endif + +/*---------------------------------------------------------------------------*/ /* Exception handling. */ #ifdef CYGPKG_KERNEL_EXCEPTIONS diff --git a/packages/kernel/current/src/common/thread.cxx b/packages/kernel/current/src/common/thread.cxx --- a/packages/kernel/current/src/common/thread.cxx +++ b/packages/kernel/current/src/common/thread.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -752,17 +752,13 @@ Cyg_Thread::exit() #ifdef CYGPKG_KERNEL_THREADS_DESTRUCTORS cyg_ucount16 i; - Cyg_Scheduler::lock(); for (i=0; idestructors[i].fn) { destructor_fn fn = self->destructors[i].fn; CYG_ADDRWORD data = self->destructors[i].data; - Cyg_Scheduler::unlock(); fn(data); - Cyg_Scheduler::lock(); } } - Cyg_Scheduler::unlock(); #endif #ifdef CYGDBG_KERNEL_THREADS_STACK_MEASUREMENT_VERBOSE_EXIT diag_printf( "Stack usage for thread %08x: %d\n", self, diff --git a/packages/kernel/current/src/common/timer.cxx b/packages/kernel/current/src/common/timer.cxx --- a/packages/kernel/current/src/common/timer.cxx +++ b/packages/kernel/current/src/common/timer.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/debug/dbg-thread-demux.c b/packages/kernel/current/src/debug/dbg-thread-demux.c --- a/packages/kernel/current/src/debug/dbg-thread-demux.c +++ b/packages/kernel/current/src/debug/dbg-thread-demux.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/debug/dbg_gdb.cxx b/packages/kernel/current/src/debug/dbg_gdb.cxx --- a/packages/kernel/current/src/debug/dbg_gdb.cxx +++ b/packages/kernel/current/src/debug/dbg_gdb.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/instrmnt/meminst.cxx b/packages/kernel/current/src/instrmnt/meminst.cxx --- a/packages/kernel/current/src/instrmnt/meminst.cxx +++ b/packages/kernel/current/src/instrmnt/meminst.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/intr/intr.cxx b/packages/kernel/current/src/intr/intr.cxx --- a/packages/kernel/current/src/intr/intr.cxx +++ b/packages/kernel/current/src/intr/intr.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sched/bitmap.cxx b/packages/kernel/current/src/sched/bitmap.cxx --- a/packages/kernel/current/src/sched/bitmap.cxx +++ b/packages/kernel/current/src/sched/bitmap.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sched/lottery.cxx b/packages/kernel/current/src/sched/lottery.cxx --- a/packages/kernel/current/src/sched/lottery.cxx +++ b/packages/kernel/current/src/sched/lottery.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sched/mlqueue.cxx b/packages/kernel/current/src/sched/mlqueue.cxx --- a/packages/kernel/current/src/sched/mlqueue.cxx +++ b/packages/kernel/current/src/sched/mlqueue.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -68,20 +68,6 @@ #ifdef CYGSEM_KERNEL_SCHED_MLQUEUE -//------------------------------------------------------------------------- -// Some local tracing control - a default. -#ifdef CYGDBG_USE_TRACING -# if !defined( CYGDBG_INFRA_DEBUG_TRACE_ASSERT_SIMPLE ) && \ - !defined( CYGDBG_INFRA_DEBUG_TRACE_ASSERT_FANCY ) - // ie. not a tracing implementation that takes a long time to output - -# ifndef CYGDBG_KERNEL_TRACE_TIMESLICE -# define CYGDBG_KERNEL_TRACE_TIMESLICE -# endif // control not already defined - -# endif // trace implementation not ..._SIMPLE && not ..._FANCY -#endif // CYGDBG_USE_TRACING - //========================================================================== // Cyg_Scheduler_Implementation class static members diff --git a/packages/kernel/current/src/sched/sched.cxx b/packages/kernel/current/src/sched/sched.cxx --- a/packages/kernel/current/src/sched/sched.cxx +++ b/packages/kernel/current/src/sched/sched.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/bin_sem.cxx b/packages/kernel/current/src/sync/bin_sem.cxx --- a/packages/kernel/current/src/sync/bin_sem.cxx +++ b/packages/kernel/current/src/sync/bin_sem.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/cnt_sem.cxx b/packages/kernel/current/src/sync/cnt_sem.cxx --- a/packages/kernel/current/src/sync/cnt_sem.cxx +++ b/packages/kernel/current/src/sync/cnt_sem.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/cnt_sem2.cxx b/packages/kernel/current/src/sync/cnt_sem2.cxx --- a/packages/kernel/current/src/sync/cnt_sem2.cxx +++ b/packages/kernel/current/src/sync/cnt_sem2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/flag.cxx b/packages/kernel/current/src/sync/flag.cxx --- a/packages/kernel/current/src/sync/flag.cxx +++ b/packages/kernel/current/src/sync/flag.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/mbox.cxx b/packages/kernel/current/src/sync/mbox.cxx --- a/packages/kernel/current/src/sync/mbox.cxx +++ b/packages/kernel/current/src/sync/mbox.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/mqueue.cxx b/packages/kernel/current/src/sync/mqueue.cxx --- a/packages/kernel/current/src/sync/mqueue.cxx +++ b/packages/kernel/current/src/sync/mqueue.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/src/sync/mutex.cxx b/packages/kernel/current/src/sync/mutex.cxx --- a/packages/kernel/current/src/sync/mutex.cxx +++ b/packages/kernel/current/src/sync/mutex.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/bin_sem0.cxx b/packages/kernel/current/tests/bin_sem0.cxx --- a/packages/kernel/current/tests/bin_sem0.cxx +++ b/packages/kernel/current/tests/bin_sem0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/bin_sem1.cxx b/packages/kernel/current/tests/bin_sem1.cxx --- a/packages/kernel/current/tests/bin_sem1.cxx +++ b/packages/kernel/current/tests/bin_sem1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/bin_sem2.cxx b/packages/kernel/current/tests/bin_sem2.cxx --- a/packages/kernel/current/tests/bin_sem2.cxx +++ b/packages/kernel/current/tests/bin_sem2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/clock0.cxx b/packages/kernel/current/tests/clock0.cxx --- a/packages/kernel/current/tests/clock0.cxx +++ b/packages/kernel/current/tests/clock0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/clock1.cxx b/packages/kernel/current/tests/clock1.cxx --- a/packages/kernel/current/tests/clock1.cxx +++ b/packages/kernel/current/tests/clock1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/clockcnv.cxx b/packages/kernel/current/tests/clockcnv.cxx --- a/packages/kernel/current/tests/clockcnv.cxx +++ b/packages/kernel/current/tests/clockcnv.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/clocktruth.cxx b/packages/kernel/current/tests/clocktruth.cxx --- a/packages/kernel/current/tests/clocktruth.cxx +++ b/packages/kernel/current/tests/clocktruth.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/cnt_sem0.cxx b/packages/kernel/current/tests/cnt_sem0.cxx --- a/packages/kernel/current/tests/cnt_sem0.cxx +++ b/packages/kernel/current/tests/cnt_sem0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/cnt_sem1.cxx b/packages/kernel/current/tests/cnt_sem1.cxx --- a/packages/kernel/current/tests/cnt_sem1.cxx +++ b/packages/kernel/current/tests/cnt_sem1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/except1.cxx b/packages/kernel/current/tests/except1.cxx --- a/packages/kernel/current/tests/except1.cxx +++ b/packages/kernel/current/tests/except1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //================================================================= diff --git a/packages/kernel/current/tests/flag0.cxx b/packages/kernel/current/tests/flag0.cxx --- a/packages/kernel/current/tests/flag0.cxx +++ b/packages/kernel/current/tests/flag0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/flag1.cxx b/packages/kernel/current/tests/flag1.cxx --- a/packages/kernel/current/tests/flag1.cxx +++ b/packages/kernel/current/tests/flag1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/intr0.cxx b/packages/kernel/current/tests/intr0.cxx --- a/packages/kernel/current/tests/intr0.cxx +++ b/packages/kernel/current/tests/intr0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //================================================================= diff --git a/packages/kernel/current/tests/kcache1.c b/packages/kernel/current/tests/kcache1.c --- a/packages/kernel/current/tests/kcache1.c +++ b/packages/kernel/current/tests/kcache1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kcache2.c b/packages/kernel/current/tests/kcache2.c --- a/packages/kernel/current/tests/kcache2.c +++ b/packages/kernel/current/tests/kcache2.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kclock0.c b/packages/kernel/current/tests/kclock0.c --- a/packages/kernel/current/tests/kclock0.c +++ b/packages/kernel/current/tests/kclock0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kclock1.c b/packages/kernel/current/tests/kclock1.c --- a/packages/kernel/current/tests/kclock1.c +++ b/packages/kernel/current/tests/kclock1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kexcept1.c b/packages/kernel/current/tests/kexcept1.c --- a/packages/kernel/current/tests/kexcept1.c +++ b/packages/kernel/current/tests/kexcept1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //================================================================= diff --git a/packages/kernel/current/tests/kflag0.c b/packages/kernel/current/tests/kflag0.c --- a/packages/kernel/current/tests/kflag0.c +++ b/packages/kernel/current/tests/kflag0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kflag1.c b/packages/kernel/current/tests/kflag1.c --- a/packages/kernel/current/tests/kflag1.c +++ b/packages/kernel/current/tests/kflag1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kill.cxx b/packages/kernel/current/tests/kill.cxx --- a/packages/kernel/current/tests/kill.cxx +++ b/packages/kernel/current/tests/kill.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kintr0.c b/packages/kernel/current/tests/kintr0.c --- a/packages/kernel/current/tests/kintr0.c +++ b/packages/kernel/current/tests/kintr0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/klock.c b/packages/kernel/current/tests/klock.c --- a/packages/kernel/current/tests/klock.c +++ b/packages/kernel/current/tests/klock.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kmbox1.c b/packages/kernel/current/tests/kmbox1.c --- a/packages/kernel/current/tests/kmbox1.c +++ b/packages/kernel/current/tests/kmbox1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kmutex0.c b/packages/kernel/current/tests/kmutex0.c --- a/packages/kernel/current/tests/kmutex0.c +++ b/packages/kernel/current/tests/kmutex0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kmutex1.c b/packages/kernel/current/tests/kmutex1.c --- a/packages/kernel/current/tests/kmutex1.c +++ b/packages/kernel/current/tests/kmutex1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kmutex3.c b/packages/kernel/current/tests/kmutex3.c --- a/packages/kernel/current/tests/kmutex3.c +++ b/packages/kernel/current/tests/kmutex3.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kmutex4.c b/packages/kernel/current/tests/kmutex4.c --- a/packages/kernel/current/tests/kmutex4.c +++ b/packages/kernel/current/tests/kmutex4.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kphilo.c b/packages/kernel/current/tests/kphilo.c --- a/packages/kernel/current/tests/kphilo.c +++ b/packages/kernel/current/tests/kphilo.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/ksched1.c b/packages/kernel/current/tests/ksched1.c --- a/packages/kernel/current/tests/ksched1.c +++ b/packages/kernel/current/tests/ksched1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/ksem0.c b/packages/kernel/current/tests/ksem0.c --- a/packages/kernel/current/tests/ksem0.c +++ b/packages/kernel/current/tests/ksem0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/ksem1.c b/packages/kernel/current/tests/ksem1.c --- a/packages/kernel/current/tests/ksem1.c +++ b/packages/kernel/current/tests/ksem1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kthread0.c b/packages/kernel/current/tests/kthread0.c --- a/packages/kernel/current/tests/kthread0.c +++ b/packages/kernel/current/tests/kthread0.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/kthread1.c b/packages/kernel/current/tests/kthread1.c --- a/packages/kernel/current/tests/kthread1.c +++ b/packages/kernel/current/tests/kthread1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/mbox1.cxx b/packages/kernel/current/tests/mbox1.cxx --- a/packages/kernel/current/tests/mbox1.cxx +++ b/packages/kernel/current/tests/mbox1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/mqueue1.cxx b/packages/kernel/current/tests/mqueue1.cxx --- a/packages/kernel/current/tests/mqueue1.cxx +++ b/packages/kernel/current/tests/mqueue1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //======================================================================== diff --git a/packages/kernel/current/tests/mutex0.cxx b/packages/kernel/current/tests/mutex0.cxx --- a/packages/kernel/current/tests/mutex0.cxx +++ b/packages/kernel/current/tests/mutex0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/mutex1.cxx b/packages/kernel/current/tests/mutex1.cxx --- a/packages/kernel/current/tests/mutex1.cxx +++ b/packages/kernel/current/tests/mutex1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/mutex2.cxx b/packages/kernel/current/tests/mutex2.cxx --- a/packages/kernel/current/tests/mutex2.cxx +++ b/packages/kernel/current/tests/mutex2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/mutex3.cxx b/packages/kernel/current/tests/mutex3.cxx --- a/packages/kernel/current/tests/mutex3.cxx +++ b/packages/kernel/current/tests/mutex3.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/philo.cxx b/packages/kernel/current/tests/philo.cxx --- a/packages/kernel/current/tests/philo.cxx +++ b/packages/kernel/current/tests/philo.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/release.cxx b/packages/kernel/current/tests/release.cxx --- a/packages/kernel/current/tests/release.cxx +++ b/packages/kernel/current/tests/release.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/sched1.cxx b/packages/kernel/current/tests/sched1.cxx --- a/packages/kernel/current/tests/sched1.cxx +++ b/packages/kernel/current/tests/sched1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/smp.cxx b/packages/kernel/current/tests/smp.cxx --- a/packages/kernel/current/tests/smp.cxx +++ b/packages/kernel/current/tests/smp.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -67,9 +67,6 @@ #include #include -#define NTHREADS 1 -#include "testaux.hxx" - //========================================================================== #if defined(CYGPKG_KERNEL_SMP_SUPPORT) && \ @@ -82,6 +79,9 @@ //========================================================================== +#define NTHREADS 1 +#include "testaux.hxx" + #define STACK_SIZE CYGNUM_HAL_STACK_SIZE_TYPICAL #define NTHREADS_MAX (CYGNUM_KERNEL_CPU_MAX*3) diff --git a/packages/kernel/current/tests/stress_threads.c b/packages/kernel/current/tests/stress_threads.c --- a/packages/kernel/current/tests/stress_threads.c +++ b/packages/kernel/current/tests/stress_threads.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/sync2.cxx b/packages/kernel/current/tests/sync2.cxx --- a/packages/kernel/current/tests/sync2.cxx +++ b/packages/kernel/current/tests/sync2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/sync3.cxx b/packages/kernel/current/tests/sync3.cxx --- a/packages/kernel/current/tests/sync3.cxx +++ b/packages/kernel/current/tests/sync3.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/tcdiag.cxx b/packages/kernel/current/tests/tcdiag.cxx --- a/packages/kernel/current/tests/tcdiag.cxx +++ b/packages/kernel/current/tests/tcdiag.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/testaux.h b/packages/kernel/current/tests/testaux.h --- a/packages/kernel/current/tests/testaux.h +++ b/packages/kernel/current/tests/testaux.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/testaux.hxx b/packages/kernel/current/tests/testaux.hxx --- a/packages/kernel/current/tests/testaux.hxx +++ b/packages/kernel/current/tests/testaux.hxx @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/thread0.cxx b/packages/kernel/current/tests/thread0.cxx --- a/packages/kernel/current/tests/thread0.cxx +++ b/packages/kernel/current/tests/thread0.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/thread1.cxx b/packages/kernel/current/tests/thread1.cxx --- a/packages/kernel/current/tests/thread1.cxx +++ b/packages/kernel/current/tests/thread1.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/thread2.cxx b/packages/kernel/current/tests/thread2.cxx --- a/packages/kernel/current/tests/thread2.cxx +++ b/packages/kernel/current/tests/thread2.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/thread_gdb.c b/packages/kernel/current/tests/thread_gdb.c --- a/packages/kernel/current/tests/thread_gdb.c +++ b/packages/kernel/current/tests/thread_gdb.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/timeslice.c b/packages/kernel/current/tests/timeslice.c --- a/packages/kernel/current/tests/timeslice.c +++ b/packages/kernel/current/tests/timeslice.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/kernel/current/tests/tm_basic.cxx b/packages/kernel/current/tests/tm_basic.cxx --- a/packages/kernel/current/tests/tm_basic.cxx +++ b/packages/kernel/current/tests/tm_basic.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -149,8 +149,10 @@ static cyg_handle_t mutex_test_thread_ha static cyg_mbox test_mboxes[NMBOXES]; static cyg_handle_t test_mbox_handles[NMBOXES]; static fun_times mbox_ft[NMBOXES]; +#ifdef CYGMFN_KERNEL_SYNCH_MBOXT_PUT_CAN_WAIT static cyg_thread mbox_test_thread; static cyg_handle_t mbox_test_thread_handle; +#endif static cyg_sem_t test_semaphores[NSEMAPHORES]; static fun_times semaphore_ft[NSEMAPHORES]; @@ -170,14 +172,14 @@ static fun_times alarm_ft[NALARMS]; static long rtc_resolution[] = CYGNUM_KERNEL_COUNTERS_RTC_RESOLUTION; static long ns_per_system_clock; -#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_LATENCY) +#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_LATENCY) && defined(HAL_CLOCK_LATENCY) // Data kept by kernel real time clock measuring clock interrupt latency extern cyg_tick_count total_clock_latency, total_clock_interrupts; extern cyg_int32 min_clock_latency, max_clock_latency; extern bool measure_clock_latency; #endif -#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) +#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) && defined(HAL_CLOCK_LATENCY) extern cyg_tick_count total_clock_dsr_latency, total_clock_dsr_calls; extern cyg_int32 min_clock_dsr_latency, max_clock_dsr_latency; extern bool measure_clock_latency; @@ -262,7 +264,7 @@ reset_clock_latency_measurement(void) total_clock_interrupts = 0; min_clock_latency = 0x7FFFFFFF; max_clock_latency = 0; -#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) +#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) && defined(HAL_CLOCK_LATENCY) total_clock_dsr_latency = 0; total_clock_dsr_calls = 0; min_clock_dsr_latency = 0x7FFFFFFF; @@ -1630,7 +1632,7 @@ run_all_tests(CYG_ADDRESS id) enable_clock_latency_measurement(); #endif -#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) +#if defined(CYGVAR_KERNEL_COUNTERS_CLOCK_DSR_LATENCY) && defined(HAL_CLOCK_LATENCY) disable_clock_latency_measurement(); clock_ave = (total_clock_dsr_latency*1000) / total_clock_dsr_calls; show_ticks_in_us(clock_ave); diff --git a/packages/language/c/libc/common/current/ChangeLog b/packages/language/c/libc/common/current/ChangeLog --- a/packages/language/c/libc/common/current/ChangeLog +++ b/packages/language/c/libc/common/current/ChangeLog @@ -36,7 +36,7 @@ 2000-05-02 Jonathan Larmour + + * cdl/signals.cdl: Don't build signal2 test when it'll N/A + anyway. + 2002-04-30 Jesper Skov * cdl/signals.cdl: Added @@ -81,7 +86,7 @@ 2000-05-02 Jonathan Larmour + + * include/net/netdb.h: Include netinet/in.h for the in_addr use in + declarations. + 2002-05-14 Jesper Skov * src/tftp_dummy_file.c: Fixed warnings. diff --git a/packages/net/common/current/include/net/netdb.h b/packages/net/common/current/include/net/netdb.h --- a/packages/net/common/current/include/net/netdb.h +++ b/packages/net/common/current/include/net/netdb.h @@ -131,6 +131,7 @@ int getnameinfo (const struct sockaddr * unsigned int flags); // Miscellaneous address manipulation functions +#include char *inet_ntoa(struct in_addr); char *inet_ntop(int af, char *src, char *dst, size_t len); int inet_pton(int af, char *src, char *dst); diff --git a/packages/net/ftpclient/current/ChangeLog b/packages/net/ftpclient/current/ChangeLog --- a/packages/net/ftpclient/current/ChangeLog +++ b/packages/net/ftpclient/current/ChangeLog @@ -41,7 +41,7 @@ 2001-11-04 Andrew Lunn + + * cdl/dns.cdl (CYGPKG_NS_DNS_BUILD): Require thread destructors in + kernel. + * include/dns_impl.inl: Instead of using cyg_thread_get_data + and _set_data directly, instead use store_hent and free_stored_hent + defined by includer. + * src/dns.c: Define store_hent() and free_stored_hent() and make + them use thread destructors thus fixing a memory leak. + 2002-05-14 Jesper Skov * tests/dns2.c: Fix warning. @@ -154,7 +164,7 @@ 2001-09-18 Jesper Skov h_addr_list[0], addr, sizeof(struct in_addr)); - cyg_thread_set_data(ptdindex, (CYG_ADDRWORD)hent); + store_hent(hent); } cyg_drv_mutex_unlock(&dns_mutex); @@ -447,18 +443,14 @@ gethostbyname(const char * hostname) return NULL; } - /* See if there is answer to and old query. If so free the memory + /* See if there is an answer to an old query. If so free the memory it uses */ - hent = (struct hostent *)cyg_thread_get_data(ptdindex); - if (hent) { - free_hent(hent); - cyg_thread_set_data(ptdindex, (CYG_ADDRWORD)NULL); - } + free_stored_hent(); if (!valid_hostname(hostname)) { /* It could be a dot address */ hent = dot_hostname(hostname); - cyg_thread_set_data(ptdindex, (CYG_ADDRWORD)hent); + store_hent(hent); CYG_REPORT_RETVAL( hent ); return hent; } @@ -486,7 +478,7 @@ gethostbyname(const char * hostname) hent = parse_answer(msg, DNS_TYPE_A); if (hent) { cyg_drv_mutex_unlock(&dns_mutex); - cyg_thread_set_data(ptdindex, (CYG_ADDRWORD)hent); + store_hent(hent); CYG_REPORT_RETVAL( hent ); return hent; } @@ -524,7 +516,7 @@ gethostbyname(const char * hostname) } cyg_drv_mutex_unlock(&dns_mutex); - cyg_thread_set_data(ptdindex, (CYG_ADDRWORD)hent); + store_hent(hent); CYG_REPORT_RETVAL( hent ); return hent; } diff --git a/packages/net/ns/dns/current/include/dns_priv.h b/packages/net/ns/dns/current/include/dns_priv.h --- a/packages/net/ns/dns/current/include/dns_priv.h +++ b/packages/net/ns/dns/current/include/dns_priv.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= diff --git a/packages/net/ns/dns/current/src/dns.c b/packages/net/ns/dns/current/src/dns.c --- a/packages/net/ns/dns/current/src/dns.c +++ b/packages/net/ns/dns/current/src/dns.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= @@ -56,6 +56,11 @@ // //============================================================================= +#include +#ifdef CYGPKG_KERNEL +# include +# include +#endif #include #include #include /* Tracing support */ @@ -138,6 +143,41 @@ alloc_hent(void) return hent; } +/* Thread destructor used to free stuff stored in per-thread data slot. */ +static void +thread_destructor(CYG_ADDRWORD data) +{ + struct hostent *hent; + hent = (struct hostent *)cyg_thread_get_data(index); + if (hent) + free_hent(hent); + return; + data=data; +} + +/* Store the hent away in the per-thread data. */ +static void +store_hent(struct hostent *hent) +{ + // Prevent memory leaks by setting a destructor to be + // called on thread exit to free per-thread data. + cyg_thread_add_destructor( &thread_destructor, 0 ); + cyg_thread_set_data(index, (CYG_ADDRWORD)hent); +} + +/* If there is an answer to an old query, free the memory it uses. */ +static void +free_stored_hent(void) +{ + struct hostent *hent; + hent = (struct hostent *)cyg_thread_get_data(index); + if (hent) { + free_hent(hent); + cyg_thread_set_data(index, (CYG_ADDRWORD)NULL); + cyg_thread_rem_destructor( &thread_destructor, 0 ); + } +} + /* Send the query to the server and read the response back. Return -1 if it fails, otherwise put the response back in msg and return the length of the response. */ diff --git a/packages/net/ns/dns/current/tests/dns1.c b/packages/net/ns/dns/current/tests/dns1.c --- a/packages/net/ns/dns/current/tests/dns1.c +++ b/packages/net/ns/dns/current/tests/dns1.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/net/ns/dns/current/tests/dns2.c b/packages/net/ns/dns/current/tests/dns2.c --- a/packages/net/ns/dns/current/tests/dns2.c +++ b/packages/net/ns/dns/current/tests/dns2.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/net/snmp/agent/current/ChangeLog b/packages/net/snmp/agent/current/ChangeLog --- a/packages/net/snmp/agent/current/ChangeLog +++ b/packages/net/snmp/agent/current/ChangeLog @@ -401,7 +401,7 @@ 2000-05-31 Hugo Tyson + + * src/lib/recv.c: Fix warning. socket.h declarations are not + available to the kernel code. Added missing argument in the + recvfrom call. + 2002-05-14 Jesper Skov * include/netinet6/in6.h: Fixed warnings. diff --git a/packages/net/tcpip/current/src/lib/recv.c b/packages/net/tcpip/current/src/lib/recv.c --- a/packages/net/tcpip/current/src/lib/recv.c +++ b/packages/net/tcpip/current/src/lib/recv.c @@ -35,10 +35,11 @@ #include #include +extern ssize_t recvfrom (int, void *, size_t, int, struct sockaddr *, socklen_t *); + ssize_t -recv(int s, const void *buf, size_t buflen, - int flags) +recv(int s, void *buf, size_t buflen, int flags) { - return(recvfrom(s,buf,buflen,NULL,0)); + return(recvfrom(s,buf,buflen,flags,NULL,0)); } diff --git a/packages/pkgconf/fixhtml.tcl b/packages/pkgconf/fixhtml.tcl --- a/packages/pkgconf/fixhtml.tcl +++ b/packages/pkgconf/fixhtml.tcl @@ -10,36 +10,36 @@ # #=============================================================================== #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### #=============================================================================== ######DESCRIPTIONBEGIN#### diff --git a/packages/pkgconf/rules.doc b/packages/pkgconf/rules.doc --- a/packages/pkgconf/rules.doc +++ b/packages/pkgconf/rules.doc @@ -6,36 +6,36 @@ # #============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### #============================================================================= #####DESCRIPTIONBEGIN#### diff --git a/packages/pkgconf/rules.mak b/packages/pkgconf/rules.mak --- a/packages/pkgconf/rules.mak +++ b/packages/pkgconf/rules.mak @@ -6,36 +6,36 @@ # #============================================================================= #####ECOSGPLCOPYRIGHTBEGIN#### -# ------------------------------------------- -# This file is part of eCos, the Embedded Configurable Operating System. -# Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. -# -# eCos is free software; you can redistribute it and/or modify it under -# the terms of the GNU General Public License as published by the Free -# Software Foundation; either version 2 or (at your option) any later version. -# -# eCos is distributed in the hope that it will be useful, but WITHOUT ANY -# WARRANTY; without even the implied warranty of MERCHANTABILITY or -# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License -# for more details. -# -# You should have received a copy of the GNU General Public License along -# with eCos; if not, write to the Free Software Foundation, Inc., -# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -# -# As a special exception, if other files instantiate templates or use macros -# or inline functions from this file, or you compile this file and link it -# with other works to produce a work based on this file, this file does not -# by itself cause the resulting work to be covered by the GNU General Public -# License. However the source code for this file must still be made available -# in accordance with section (3) of the GNU General Public License. -# -# This exception does not invalidate any other reasons why a work based on -# this file might be covered by the GNU General Public License. -# -# Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -# at http://sources.redhat.com/ecos/ecos-license -# ------------------------------------------- +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- #####ECOSGPLCOPYRIGHTEND#### #============================================================================= #####DESCRIPTIONBEGIN#### diff --git a/packages/pkgconf/stylesheet.dsl b/packages/pkgconf/stylesheet.dsl --- a/packages/pkgconf/stylesheet.dsl +++ b/packages/pkgconf/stylesheet.dsl @@ -7,36 +7,38 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/packages/redboot/current/ChangeLog b/packages/redboot/current/ChangeLog --- a/packages/redboot/current/ChangeLog +++ b/packages/redboot/current/ChangeLog @@ -1,3 +1,78 @@ +2002-05-23 Jonathan Larmour + + * src/net/dns.c (store_hent): New function. DNS package now requires + this instead of the cyg_thread_get_data calls. + (free_stored_hent): New function. Ditto. + +2002-05-23 Gary Thomas + + * doc/redboot_cmds.sgml: Document new HTTP download mode. + + * src/net/tcp.c: Improve some interfaces. Add support for + outgoing (__tcp_open) connections. + + * src/net/net_io.c (net_io_flush): Use improved TCP interfaces. + + * src/main.c (_mon_write_char): Map '\n' => '\r\n'. This used + to be done by diag_printf(), but that was the wrong place for it. + + * include/net/net.h: Add support for TCP outgoing connections. + + * src/net/http_client.c: + * include/net/http.h: New file(s) - HTTP client support. + + * src/load.c: + * cdl/redboot.cdl: Support HTTP download mode. + +2002-05-23 Jesper Skov + + * doc/redboot.sgml: Moved the editing and resource sections to + this document. Added new section on RedBoot (startup) modes. + * doc/redboot_cmds.sgml: Removed the editing and resource + sections. + * doc/redboot_installing.sgml: Changed a couple of platform + descriptions. + * doc/redboot_rebuilding.sgml: Make use of mode/config + consistent. Removed mode section. + +2002-05-22 Jesper Skov + + * doc/redboot_rebuilding.sgml: Added a note about redboot growing + beyond its slot limits. + Rewrote the RedBoot rebuilding documentation. + + * src/flash.c (fis_create): Clarify error message. Get rid of bool + flag slot_found that only duplicated fis variable state. + +2002-05-21 Gary Thomas + + * src/xyzModem.h: + * src/xyzModem.c: + * src/load.c: Purge mention of Z-modem until it's implemented. + +2002-05-21 Jesper Skov + + * src/flash.c (fis_create): Removed one of the three questions to + verify. + * doc/redboot_rebuilding.sgml: Removed the query lines from the + docs. + + * doc/redboot_installing.sgml: Removed all the free RAM related + resource descriptions. Left in a few timer resource descriptions. + * doc/redboot_cmds.sgml: Refer to platform sections for additional + platform-specific resource usage. + + * doc/redboot_installing.sgml: Removed all platform specific + references to the updating section which told the user to use + specific flash paramemters. All this is now handled + automagically. + + * src/alias.c (lookup_alias): FREEMEMHI is just the high address + masked to 1KB alignment. + + * doc/redboot_cmds.sgml: Added load disk example. + Added section on RedBoot resources. + 2002-05-18 Gary Thomas * src/main.c (do_baud_rate): Improve safety by asking for verification @@ -2395,7 +2470,7 @@ 2000-07-12 Gary Thomas + + +RedBoot Editing Commands +RedBootediting commands +editing commands +commandseditingRedBoot +uses the following line editing commands. +NOTE + +In this description, ^A means the character formed +by typing the letter “A” while holding down the control key. + + +Delete (0x7F) or +Backspace (0x08) +erases the character to the left of the cursor. + + +^A +moves the cursor (insertion point) to the beginning of the line. + + +^K +erases all characters on the line from the cursor to the end. + + +^E +positions the cursor to the end of the line. + + +^D +erases the character under the cursor. + + +^F +moves the cursor one character to the right. + + +^B +moves the cursor one character to the left. + + +^P +replaces the current line by a previous line from the history buffer. +A small number of lines +can be kept as history. Using ^P (and ^N), the current line can be replaced +by any one of the previously typed lines. + + +^N +replaces the current line by the next line from the history buffer. + + +In the case of the fconfig +command, additional editing commands are possible. +As data are entered for this command, the current/previous value +will be displayed and the cursor placed at the end of that data. +The user may use the editing keys (above) to move around in the data +to modify it as appropriate. +Additionally, when certain +characters are entered at the end of the current value, +i.e. entered separately, certain behavior is elicited. + + +^ (caret) switch to editing the previous item in the +fconfig list. If fconfig edits item A, followed by item B, +pressing ^ when changing item B, allows you to change item A. This is similar +to the up arrow. +Note: ^P and ^N do not have the same meaning while editing +fconfig data and should not be used. + + +. (period) stop editing any further items. This does not change +the current item. + +Return leaves the value +for this item unchanged. Currently it is not possible to step through the +value for the start-up script; it must always be retyped. + + + + + +RedBoot Startup Mode + + RedBootmode + RedBootstartup mode + + +RedBoot can normally be configured to run in a number of startup +modes (or just "modes" for short), determining its location of +residence and its location of execution: + + RAM mode + In this mode, RedBoot both resides and executes from + RAM memory. This is used for updating a primary ROM + mode image in situ and sometimes as part of the RedBoot installation + on the board when there's already an existing (non-RedBoot) boot + monitor available. + + + ROM mode + In this mode, RedBoot both resides and executes from + ROM memory (flash or EPROM). This mode is used when there are limited + RAM resources. The flash commands cannot update the region of flash + where the RedBoot image resides. In order to update the RedBoot image + in flash, it is necessary to run a RAM mode instance of + RedBoot. + + + ROMRAM mode + In this mode, RedBoot resides in ROM memory (flash or + EPROM), but is copied to RAM memory before it starts executing. The + RAM footprint is larger than for ROM mode, but there are two + advantages to make up for this: it normally runs faster (relevant + only on slower boards) and it is able to update the flash region + where the image resides. + + + +The chosen mode has influence on flash and RAM resource usage (see +) and the procedure of an in situ update +of RedBoot in flash (see ). + +The startup mode is controlled by the option CYG_HAL_STARTUP +which resides in the platform HAL. Some platforms provide only some of +the RAM, ROM, and ROMRAM modes, others provide additional +modes. + +To see mode of a currently executing RedBoot, issue the +version command, which prints the RedBoot banner, +including the startup mode (here ROM): +RedBoot>version + +RedBoot(tm) bootstrap and debug environment [ROM] +Non-certified release, version UNKNOWN - built 13:31:57, May 17 2002 + + + + + + +RedBoot Resource Usage + + RedBootresource usage + + +RedBoot takes up both flash and RAM resources depending on its +startup mode and number of enabled features. There are also other +resources used by RedBoot, such as timers. Platform-specific resources +used by RedBoot are listed in the platform specific parts of this +manual. + + + +Flash Resources +On many platforms, a ROM mode RedBoot image resides in the first +flash sectors, working as the board's primary boot monitor. On these +platforms, it is also normal to reserve a similar amount of flash for +a secondary RAM mode image, which is used when updating the primary +ROM mode image. +On other platforms, a ROMRAM mode RedBoot image is used as the +primary boot monitor. On these platforms there is not normally +reserved space for a RAM mode RedBoot image, since the ROMRAM mode +RedBoot is capable of updating the primary boot monitor image. +Most platforms also contain a FIS directory (keeping track of +available flash space) and a RedBoot config block (containing RedBoot +board configuration data). +To see the amount of reserved flash memory, run the fis +list command: +RedBoot> fis list +Name FLASH addr Mem addr Length Entry point +RedBoot 0x00000000 0x00000000 0x00020000 0x00000000 +RedBoot[RAM] 0x00020000 0x06020000 0x00020000 0x060213C0 +RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000 +FIS directory 0x00070000 0x00070000 0x0000F000 0x00000000 + + + + + +RAM Resources + +RedBoot reserves RAM space for its run-time data, and such +things as CPU exception/interrupt tables. It normally does so at the +bottom of the memory map. It may also reserve space at the top of the +memory map for configurable RedBoot features such as the net stack +and zlib decompression support. +To see the actual amount of reserved space, issue the +version command, which prints the RedBoot banner, +including the RAM usage: +RedBoot> version + +RedBoot(tm) bootstrap and debug environment [ROM] +Non-certified release, version UNKNOWN - built 13:31:57, May 17 2002 + +Platform: FooBar (SH 7615) +Copyright (C) 2000, 2001, 2002, Red Hat, Inc. + +RAM: 0x06000000-0x06080000, 0x06012498-0x06061000 available +FLASH: 0x00000000 - 0x00080000, 8 blocks of 0x00010000 bytes each. + + + +To simplify operations that temporarily need data in free +memory, the limits of free RAM are also available as aliases (aligned +to the nearest kilo-byte limit). These are named +FREEMEMLOFREEMEMLO and +FREEMEMHIFREEMEMHI, and can +be used in commands like any user defined alias: +RedBoot> load -r -b %{FREEMEMLO} file +Raw file loaded 0x06012800-0x06013e53, assumed entry at 0x06012800 + + +RedBoot> x -b %{FREEMEMHI} +06061000: 86 F5 EB D8 3D 11 51 F2 96 F4 B2 DC 76 76 8F 77 |....=.Q.....vv.w| +06061010: E6 55 DD DB F3 75 5D 15 E0 F3 FC D9 C8 73 1D DA |.U...u]......s..| + + + + + Configuring the RedBoot Environment configuring the RedBoot environment diff --git a/packages/redboot/current/doc/redboot_cmds.sgml b/packages/redboot/current/doc/redboot_cmds.sgml --- a/packages/redboot/current/doc/redboot_cmds.sgml +++ b/packages/redboot/current/doc/redboot_cmds.sgml @@ -13,27 +13,68 @@ Given the extensible and configurable nature of eCos and RedBoot, there may be extended or enhanced sets of commands available. -The basic format for commands is: RedBoot> COMMAND [-S] [-s val] operand -Commands may require additional information beyond the basic +The basic format for commands is: RedBoot> COMMAND [-S]... [-s val]... operand + + + +Commands may require additional information beyond the basic command name. In most cases this additional information is optional, with -suitable default values provided if they are not present. The type of information -required affects how it is specified: [-S]An -optional switch. If this switch is present, then some particular action will -take place. For example in the command -RedBoot> fis init -f - the -f switch indicates to perform a full file system -initialization. [-s val]An optional switch -which requires an associated value. For example the command: -RedBoot> load -b 0x00100000 data_filespecifies downloading -a file (via TFTP) into memory, relocating it to location 0x00100000. -operandThis format is used in a case where a command has -one operand which must always be present (no -s is required since it is always -implied). For example the command -RedBoot> go 0x10044 -specifies executing the code starting at location 0x10044. +suitable default values provided if they are not present. + + + + + + + + + Format + Description + Example + + + + + -S + A boolean switch; the behavior of the command will differ, depending +on the presence of the switch. In this example, the -f switch +indicates that a complete initialization of the FIS data should be performed. +There may be many such switches available for any given command and any or all of +them may be present, in any order. + + RedBoot> fis init -f + + + + -s val + A qualified value; the letter "s" introduces the value, qualifying it's meaning. In the +example, -b 0x100000 specifies where the memory dump should begin. +There may be many such switches available for any given command and any or all of +them may be present, in any order. + + + RedBoot> dump -b 0x100000 -l 0x20 + + + + operand + A simple value; some commands require a single parameter for which an additional +-X switch would be redundant. In the example, JFFS2 +is the name of a flash image. The image name is always required, thus is no need to qualify it with +a switch. +Note that any un-qualified operand must always appear at the end of the command. + + RedBoot> fis delete JFFS2 + + + + + + The list of available commands, and their syntax, can be obtained by -typing help at the command line: +typing help at the command line: + RedBoot> help Manage aliases kept in FLASH memory alias name [value] @@ -58,7 +99,7 @@ Help about help? Set/change IP addresses ip_address [-l <local_ip_address>] [-h <server_address>] Load a file - load [-r] [-v] [-d] [-c <channel>] [-h <host>] [-m {TFTP | xyzMODEM | disk}] + load [-r] [-v] [-d] [-c <channel>] [-h <host>] [-m {TFTP | HTTP | {x|y}MODEM | disk}] [-b <base_address>] <file_name> Network connectivity test ping [-v] [-n <count>] [-t <timeout>] [-i <IP_addr] @@ -69,7 +110,7 @@ Display RedBoot version information version Display (hex dump) a range of memory x -b <location> [-l <length>] [-s] - + Commands can be abbreviated to their shortest @@ -97,87 +138,6 @@ are typically included in RedBoot. The command set may be also be extended on a platform basis. - -RedBoot Editing Commands -RedBootediting commands -editing commands -commandseditingRedBoot -uses the following line editing commands. -NOTE - -In this description, ^A means the character formed -by typing the letter “A” while holding down the control key. - - -Delete (0x7F) or -Backspace (0x08) -erases the character to the left of the cursor. - - -^A -moves the cursor (insertion point) to the beginning of the line. - - -^K -erases all characters on the line from the cursor to the end. - - -^E -positions the cursor to the end of the line. - - -^D -erases the character under the cursor. - - -^F -moves the cursor one character to the right. - - -^B -moves the cursor one character to the left. - - -^P -replaces the current line by a previous line from the history buffer. -A small number of lines -can be kept as history. Using ^P (and ^N), the current line can be replaced -by any one of the previously typed lines. - - -^N -replaces the current line by the next line from the history buffer. - - -In the case of the fconfig -command, additional editing commands are possible. -As data are entered for this command, the current/previous value -will be displayed and the cursor placed at the end of that data. -The user may use the editing keys (above) to move around in the data -to modify it as appropriate. -Additionally, when certain -characters are entered at the end of the current value, -i.e. entered separately, certain behavior is elicited. - - -^ (caret) switch to editing the previous item in the -fconfig list. If fconfig edits item A, followed by item B, -pressing ^ when changing item B, allows you to change item A. This is similar -to the up arrow. -Note: ^P and ^N do not have the same meaning while editing -fconfig data and should not be used. - - -. (period) stop editing any further items. This does not change -the current item. - -Return leaves the value -for this item unchanged. Currently it is not possible to step through the -value for the start-up script; it must always be retyped. - - - - Common Commands @@ -201,7 +161,7 @@ value for the start-up script; it must a Arguments - + @@ -251,43 +211,43 @@ then the value will be saved and used wh Examples Set an alias. - + RedBoot> alias joe "This is Joe" Update RedBoot non-volatile configuration - continue (y/n)? n - + Display an alias. - + RedBoot> alias joe 'joe' = 'This is Joe' - + Use an alias. Note: the "=" command simply echoes the command to to console. - + RedBoot> = %{joe} This is Joe - + Aliases can be nested. - + RedBoot> alias frank "Who are you? %{joe}" Update RedBoot non-volatile configuration - continue (y/n)? n RedBoot> = %{frank} Who are you? This is Joe - + Notice how the value of %{frank} changes when %{joe} is changed since the value of %{joe} is not evaluated until %{frank} is evaluated. - + RedBoot> alias joe "This is now Josephine" Update RedBoot non-volatile configuration - continue (y/n)? n RedBoot> = %{frank} Who are you? This is now Josephine - + @@ -307,7 +267,7 @@ Who are you? This is now Josephine Arguments - + @@ -348,10 +308,10 @@ then the value will be saved and used wh Examples Show the current baud rate. - + RedBoot> baudrate Baud rate = 38400 - + Change the console baud rate. In order to make this operation safer, @@ -361,13 +321,13 @@ If it doesn't work, or a less than affir "continue" prompt, then the baud rate will revert to the current value. Only after the baud rate has been firmly established will RedBoot give you an opportunity to save the value in persistent storage. - + RedBoot> baudrate -b 57600 Baud rate will be changed to 57600 - update your settings Device baud rate changed at this point Baud rate changed to 57600 - continue (y/n)? y Update RedBoot non-volatile configuration - continue (y/n)? n - + @@ -390,7 +350,7 @@ Update RedBoot non-volatile configuratio Arguments - + @@ -430,26 +390,26 @@ Update RedBoot non-volatile configuratio Examples Show the current cache state. - + RedBoot> cache Data cache: On, Instruction cache: On - + Disable the caches. - + RedBoot> cache off RedBoot> cache Data cache: Off, Instruction cache: Off - + Enable the caches. - + RedBoot> cache on RedBoot> cache Data cache: On, Instruction cache: On - + @@ -472,7 +432,7 @@ Data cache: On, Instruction cache: On Arguments - + @@ -507,7 +467,7 @@ Data cache: On, Instruction cache: On With no arguments, the channel command displays the current console channel number. -When passed an argument of 0 upwards, this command switches the console +When passed an argument of 0 upward, this command switches the console channel to that channel number. The mapping between channel numbers and physical channels is platform specific but will typically be something like channel 0 is the first serial port, channel 1 is the second, etc. @@ -521,23 +481,23 @@ starts execution. Examples Show the current channel. - + RedBoot> channel Current console channel id: 0 - + Change to an invalid channel. - + RedBoot> channel 99 **Error: bad channel number '99' - + Revert to the default channel setting (any console mode). - + RedBoot> channel -1 - + @@ -558,7 +518,7 @@ RedBoot> channel -1 Arguments - + @@ -599,22 +559,22 @@ The values printed (decimal cksum, decim Examples Checksum a buffer. - + RedBoot> cksum -b 0x100000 -l 0x100 POSIX cksum = 3286483632 256 (0xc3e3c2b0 0x00000100) - + Checksum an area of memory after loading a file. Note that the base address and length parameters are provided by the preceding load command. - + RedBoot> load -r -b %{FREEMEMLO} redboot.bin Raw file loaded 0x06012800-0x0602f0a8 RedBoot> cksum Computing cksum for area 0x06012800-0x0602f0a8 POSIX cksum = 2092197813 116904 (0x7cb467b5 0x0001c8a8) - + @@ -642,11 +602,13 @@ POSIX cksum = 2092197813 116904 (0x7cb46 Examples Show what disk partitions are available. - + RedBoot> disks +hda1 Linux Swap +hda2 Linux 00100000: 00 3E 00 06 00 06 00 06 00 00 00 00 00 00 00 00 |.>..............| 00100010: 00 00 00 78 00 70 00 60 00 60 00 60 00 60 00 60 |...x.p.`.`.`.`.`| - + @@ -673,7 +635,7 @@ 00100010: 00 00 00 78 00 70 00 60 00 60 Arguments - + @@ -742,42 +704,42 @@ raw hex value, followed by an ASCII inte Examples Display a buffer, one byte at a time. - + RedBoot> mfill -b 0x100000 -l 0x20 -p 0xDEADFACE RedBoot> x -b 0x100000 00100000: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................| 00100010: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................| - + Display a buffer, one short (16 bit) word at a time. Note in this case that the ASCII interpretation is suppressed. - + RedBoot> dump -b 0x100000 -2 00100000: FACE DEAD FACE DEAD FACE DEAD FACE DEAD 00100010: FACE DEAD FACE DEAD FACE DEAD FACE DEAD - + Display a buffer, one word (32 bit) word at a time. Note in this case that the ASCII interpretation is suppressed. - + RedBoot> dump -b 0x100000 -4 00100000: DEADFACE DEADFACE DEADFACE DEADFACE 00100010: DEADFACE DEADFACE DEADFACE DEADFACE - + Display the same buffer, using Motorola S-record format. - + RedBoot> dump -b 0x100000 -s S31500100000CEFAADDECEFAADDECEFAADDECEFAADDE8E S31500100010CEFAADDECEFAADDECEFAADDECEFAADDE7E - + Display a buffer, with visible ASCII strings. - + RedBoot> d -b 0xfe00b000 -l 0x80 0xFE00B000: 20 25 70 0A 00 00 00 00 41 74 74 65 6D 70 74 20 | %p.....Attempt | 0xFE00B010: 74 6F 20 6C 6F 61 64 20 53 2D 72 65 63 6F 72 64 |to load S-record| @@ -788,7 +750,7 @@ 0xFE00B050: 20 43 68 65 63 6B 73 75 6D 0xFE00B060: 65 20 2D 20 41 64 64 72 3A 20 25 6C 78 2C 20 25 |e - Addr: %lx, %| 0xFE00B070: 30 32 6C 58 20 3C 3E 20 25 30 32 6C 58 0A 00 00 |02lX <> %02lX...| 0xFE00B080: 45 6E 74 72 79 20 70 6F 69 6E 74 3A 20 25 70 2C |Entry point: %p,| - + @@ -808,7 +770,7 @@ 0xFE00B080: 45 6E 74 72 79 20 70 6F 69 Arguments - + @@ -852,7 +814,7 @@ were successfully completed. Show generic help. Note that the contents of this display will depend on the various configuration options for RedBoot when it was built. - + RedBoot> help Manage aliases kept in FLASH memory alias name [value] @@ -875,7 +837,7 @@ Help about help? Set/change IP addresses ip_address [-l <local_ip_address>] [-h <server_address>] Load a file - load [-r] [-v] [-d] [-h <host>] [-m {TFTP | xyzMODEM -c <channel_number>}] + load [-r] [-v] [-d] [-h <host>] [-m {TFTP | HTTP | {x|y}MODEM -c <channel_number>}] [-b <base_address>] <file_name> Compare two blocks of memory mcmp -s <location> -d <location> -l <length> [-1|-2|-4] @@ -890,11 +852,11 @@ Display RedBoot version information version Display (hex dump) a range of memory x -b <location> [-l <length>] [-s] [-1|2|4] - + Help about a command with sub-commands. - + RedBoot> help fis Manage FLASH images fis {cmds} @@ -915,7 +877,7 @@ Load image from FLASH Image System [FIS] fis load [-d] [-b <memory_load_address>] [-c] name Write raw data directly to FLASH fis write -f <flash_addr> -b <mem_base> -l <image_length> - + @@ -938,7 +900,7 @@ DNS_server_IP_address Arguments - + @@ -1004,24 +966,24 @@ that an address of 0.0.0.0 will disable Examples Display the current network settings. - + RedBoot> ip_address IP: 192.168.1.31, Default server: 192.168.1.101, DNS server IP: 0.0.0.0 - + Change the DNS server address. - + RedBoot> ip_address -d 192.168.1.101 IP: 192.168.1.31, Default server: 192.168.1.101, DNS server IP: 192.168.1.101 - + Change the default server address. - + RedBoot> ip_address -h 192.168.1.104 IP: 192.168.1.31, Default server: 192.168.1.104, DNS server IP: 192.168.1.101 - + @@ -1040,8 +1002,10 @@ IP: 192.168.1.31, Default server: 192.16 -r -m - xmodem - ymodem + + xmodem + ymodem + tftp disk @@ -1055,7 +1019,7 @@ IP: 192.168.1.31, Default server: 192.16 Arguments - + @@ -1093,31 +1057,37 @@ serial download method since it would in -m tftp - Transfer data via the network using tftp protocol. - tftp + Transfer data via the network using TFTP protocol. + TFTP + + + -m http + + Transfer data via the network using HTTP protocol. + TFTP -m xmodem Transfer data using X-modem protocol. - tftp + TFTP -m ymodem Transfer data using Y-modem protocol. - tftp + TFTP -m disk Transfer data from a local disk. - tftp + TFTP -h server_IP_address Numeric IP or DNS name - The IP address of the tftp server. + The IP address of the TFTP or HTTP server. Value set by ip_address @@ -1138,8 +1108,8 @@ xmodem or ymodem protocol. file_name String - The name of the file on the TFTP -server or the local disk. Details of how this is specified for TFTP are + The name of the file on the TFTP or HTTP +server or the local disk. Details of how this is specified for TFTP are host-specific. For local disk files, the name must be in disk: filename format. The disk portion must match one of the disk names listed by the disks command. @@ -1154,7 +1124,7 @@ names listed by the disks The load command is used to download data into the target system. Data can be loaded via a network connection, -using either the TFTP protocol, or the console serial connection using the +using either the TFTP or HTTP protocols, or the console serial connection using the X/Y modem protocol. Files may also be loaded directly from local filesystems on disk. Files to be downloaded may either be executable images in ELF executable program format, @@ -1165,13 +1135,29 @@ format or raw data. Examples -Download a Motorola S-record (or ELF) image, using TFTP, specifying the +Download a Motorola S-record (or ELF) image, using TFTP, specifying the base memory address. - -RedBoot> lo redboot.ROM -b 0x8c400000 + +RedBoot> load redboot.ROM -b 0x8c400000 Address offset = 0x0c400000 Entry point: 0x80000000, address range: 0x80000000-0x8000fe80 - + + + +Download a Motorola S-record (or ELF) image, using HTTP, specifying the +host [server] address. + +RedBoot> load /redboot.ROM -m HTTP -h 192.168.1.104 +Address offset = 0x0c400000 +Entry point: 0x80000000, address range: 0x80000000-0x8000fe80 + + + +Load an ELF file from /dev/hda1 which should be an EXT2 partition: + +RedBoot> load -mode disk hda1:hello.elf +Entry point: 0x00020000, address range: 0x00020000-0x0002fd70 + @@ -1198,7 +1184,7 @@ Entry point: 0x80000000, address range: Arguments - + @@ -1262,19 +1248,19 @@ Only the least significant 16 bits of th Examples Compare two buffers which match (result is quiet). - + RedBoot> mfill -b 0x100000 -l 0x20 -p 0xDEADFACE RedBoot> mfill -b 0x200000 -l 0x20 -p 0xDEADFACE RedBoot> mcmp -s 0x100000 -d 0x200000 -l 0x20 - + Compare two buffers which don't match. Only the first non-matching element is displayed. - + RedBoot> mcmp -s 0x100000 -d 0x200000 -l 0x30 -2 Buffers don't match - 0x00100020=0x6000, 0x00200020=0x0000 - + @@ -1301,7 +1287,7 @@ Buffers don't match - 0x00100020=0x6000, Arguments - + @@ -1365,7 +1351,7 @@ Only the least significant 16 bits of th Examples Fill a buffer with zeros. - + RedBoot> x -b 0x100000 -l 0x20 00100000: 00 3E 00 06 00 06 00 06 00 00 00 00 00 00 00 00 |.>..............| 00100010: 00 00 00 78 00 70 00 60 00 60 00 60 00 60 00 60 |...x.p.`.`.`.`.`| @@ -1373,16 +1359,16 @@ RedBoot> mfill -b 0x100000 -l RedBoot> x -b 0x100000 -l 0x20 00100000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00100010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| - + Fill a buffer with a pattern. - + RedBoot> mfill -b 0x100000 -l 0x20 -p 0xDEADFACE RedBoot> x -b 0x100000 -l 0x20 00100000: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................| 00100010: CE FA AD DE CE FA AD DE CE FA AD DE CE FA AD DE |................| - + @@ -1408,7 +1394,7 @@ 00100010: CE FA AD DE CE FA AD DE CE FA Arguments - + @@ -1482,15 +1468,15 @@ were successfully completed. Examples Test connectivity to host 192.168.1.101. - + RedBoot> ping -h 192.168.1.101 Network PING - from 192.168.1.31 to 192.168.1.101 PING - received 10 of 10 expected - + Test connectivity to host 192.168.1.101, with verbose reporting. - + RedBoot> ping -h 192.168.1.101 -v -n 4 Network PING - from 192.168.1.31 to 192.168.1.101 seq: 1, time: 1 (ticks) @@ -1498,14 +1484,14 @@ Network PING - from 192.168.1.31 to 192. seq: 3, time: 1 (ticks) seq: 4, time: 1 (ticks) PING - received 10 of 10 expected - + -Test connectivity to a non-existant host (192.168.1.109). - + +Test connectivity to a non-existent host (192.168.1.109). RedBoot> ping -h 192.168.1.109 -v -n 4 PING: Cannot reach server '192.168.1.109' (192.168.1.109) - + @@ -1537,7 +1523,7 @@ equivalent to a power-on reset condition Examples Reset the platform. - + RedBoot> reset ... Resetting.+... Waiting for network card: . Socket Communications, Inc: Low Power Ethernet CF Revision C 5V/3.3V 08/27/98 @@ -1553,7 +1539,7 @@ Copyright (C) 2000, 2001, 2002, Red Hat, RAM: 0x00000000-0x01fc0000, 0x00014748-0x01f71000 available FLASH: 0x50000000 - 0x51000000, 64 blocks of 0x00040000 bytes each. RedBoot> - + @@ -1583,13 +1569,13 @@ RedBoot> Examples Display RedBoot's version. - + RedBoot> version RedBoot(tm) debug environment - built 09:12:03, Feb 12 2001 Platform: XYZ (PowerPC 860) Copyright (C) 2000, 2001, Red Hat, Inc. RAM: 0x00000000-0x00400000 - + @@ -1619,10 +1605,10 @@ blocks of flash memory will be erased as - + RedBoot> fis init -f About to initialize [format] flash image system - continue (y/n)? n - + fis [-c] [-d] list @@ -1641,7 +1627,7 @@ used for data. - + RedBoot> fis list Name flash addr Mem addr Length Entry point RedBoot 0xA0000000 0xA0000000 0x020000 0x80000000 @@ -1651,8 +1637,8 @@ RedBoot> fis list -c +FIS directory 0xA0FE0000 0x00000000 0x020000 0x00000000 + fis free @@ -1670,11 +1656,11 @@ is not erased that does not correspond t - + RedBoot> fis free 0xA0040000 .. 0xA07C0000 0xA0840000 .. 0xA0FC0000 - + fis create -b <mem_base> -l <length> [-f <flash_addr>] [-e <entry_point>] [-r <ram_addr>] [-s <data_length>] [-n] <name> @@ -1710,7 +1696,7 @@ original value. -f The location in flash for the image, which will be inferred for extant images if not specified. If this -is not provided, the first freeVblock which is large enough will be used. +is not provided, the first free block which is large enough will be used. See fis free. -e @@ -1738,7 +1724,7 @@ space for use by applications other than the FIS directory is updated, and no data is copied from RAM to flash. This feature can be used to recreate the FIS entry if it has been destroyed. - + RedBoot> fis create RedBoot -f 0xa0000000 -b 0x8c400000 -l 0x20000 An image named ‘RedBoot’ exists - continue (y/n)? n RedBoot> fis create junk -b 0x8c400000 -l 0x20000 @@ -1746,7 +1732,7 @@ RedBoot> fis create junk -b 0 ... Program from 0x8c400000-0x8c420000 at 0xa0040000: . ... Erase from 0xa0fe0000-0xa1000000: . ... Program from 0x8c7d0000-0x8c7f0000 at 0xa0fe0000: . -If +If you are loading an existing file, then the fis create command will provide some values automatically, such as the flash address and flash length. @@ -1787,10 +1773,10 @@ of the image data after it has been load copying it from flash to RAM. - + RedBoot> fis load RedBoot[RAM] RedBoot> go - + fis delete name @@ -1801,7 +1787,7 @@ name from the FIS directory. - + RedBoot> fis list Name flash addr Mem addr Length Entry point RedBoot 0xA0000000 0xA0000000 0x020000 0x80000000 @@ -1813,7 +1799,7 @@ Delete image ‘junk’ - contin ... Erase from 0xa0040000-0xa0060000: . ... Erase from 0xa0fe0000-0xa1000000: . ... Program from 0x8c7d0000-0x8c7f0000 at 0xa0fe0000: . - + NOTE Certain images are reserved by RedBoot and cannot be deleted. @@ -1835,10 +1821,10 @@ may generate errors or warnings, or be b - + RedBoot> fis lock -f 0xa0040000 -l 0x20000 ... Lock from 0xa0040000-0xa0060000: . - + fis unlock -f <flash_addr> -l <length> @@ -1849,10 +1835,10 @@ the FIS can reuse those portions of flas - + RedBoot> fis unlock -f 0xa0040000 -l 0x20000 ... Unlock from 0xa0040000-0xa0060000: . - + fis erase -f <flash_addr> -l <length> @@ -1863,10 +1849,10 @@ to a loaded image. - + RedBoot> fis erase -f 0xa0040000 -l 0x20000 ... Erase from 0xa0040000-0xa0060000: . - + fis write -b <location> -l <length> -f <flash @@ -1918,7 +1904,7 @@ process may be stopped simply by enterin the caret (^) moves the editing back to the previous item. See “RedBoot Editing Commands”, . If any changes are made in the configuration, then the updated data -will be written back to flash after getting acknowledgement from the user. +will be written back to flash after getting acknowledgment from the user. If the optional flag -n is specified @@ -1999,7 +1985,7 @@ to execute a script at boot time. A sequ which will be executed when the system starts up. Optionally, a time-out period can be provided which allows the user to abort the startup script and proceed with normal command processing from the console. - + RedBoot> fconfig -l Run script at boot: false Use BOOTP for network configuration: false @@ -2008,11 +1994,11 @@ Default server IP address: 192.168.1.101 DNS server IP address: 192.168.1.1 GDB connection port: 9000 Network debug at boot time: false - + The following example sets a boot script and then shows it running. - + RedBoot> fconfig Run script at boot: false t Boot script: @@ -2039,7 +2025,7 @@ RedBoot 0xA0000000 0xA0000000 RedBoot config 0xA0FC0000 0xA0FC0000 0x020000 0x00000000 FIS directory 0xA0FE0000 0xA0FE0000 0x020000 0x00000000 RedBoot> - + NOTE The bold characters above indicate where something was entered on the @@ -2053,9 +2039,9 @@ the console. RedBoot supports the notion of a boot script timeout, i.e. a period of time that RedBoot waits before executing the boot time script. This period -is primarily to allow the possibility of cancelling the script. Since +is primarily to allow the possibility of canceling the script. Since a timeout value of zero (0) seconds would never allow the script to -be aborted or cancelled, this value is not allowed. If the timeout +be aborted or canceled, this value is not allowed. If the timeout value is zero, then RedBoot will abort the script execution immediately. @@ -2069,7 +2055,7 @@ commands which should be executed only b specified startup type. The following boot script illustrates this concept by having the ROM based RedBoot load and run the RAM based RedBoot. The RAM based RedBoot will then list flash images. - + RedBoot> fco Run script at boot: false t Boot script: @@ -2120,7 +2106,7 @@ RedBoot 0x00000000 0x00000000 RedBoot config 0x007DF000 0x007DF000 0x00001000 0x00000000 FIS directory 0x007E0000 0x007E0000 0x00020000 0x00000000 RedBoot> - + Executing Programs from RedBoot @@ -2152,7 +2138,7 @@ or a Linux kernel. Arguments - + @@ -2200,18 +2186,18 @@ a program and move on in the script. Examples Execute a program - no explicit output from RedBoot. - + RedBoot> go 0x40040 - + Execute a program with a timeout. - + RedBoot> go -w 10 About to start execution at 0x00000000 - abort with ^C within 10 seconds ^C RedBoot> - + Note that the starting address was implied (0x00000000 in this example). The user is prompted that execution will commence in 10 seconds. At anytime within that 10 seconds the user may type Ctrl+C @@ -2243,7 +2229,7 @@ command, either from a script or the con Arguments - + @@ -2321,7 +2307,7 @@ be relocated to the appropriate location "-s" options are used to pass information to the kernel about where a statically loaded ramdisk (initrd) is located. The "-c" option can be used to pass textual "command line" information -to the kernel. If the command line data contains any puncuation (spaces, +to the kernel. If the command line data contains any punctuation (spaces, etc), then it must be quoted using the double-quote character '"'. If the quote character is required, it should be written as '\"'. @@ -2332,14 +2318,14 @@ quote character is required, it should b Execute a Linux kernel, passing a command line, which needs relocation. The result from RedBoot is normally quiet, with the target platform being passed over to Linux immediately. - + RedBoot> exec -b 0x100000 -l 0x80000 -c "noinitrd root=/dev/mtdblock3 console=ttySA0" - + Execute a Linux kernel, default entry address and no relocation required, with a timeout. The emphasized lines are output from the loaded kernel. - + RedBoot> exec -c "console=ttyS0,38400 ip=dhcp nfsroot=/export/elfs-sh" -w 5 Now booting linux kernel: Base address 0x8c001000 Entry 0x8c210000 @@ -2348,7 +2334,7 @@ About to start execution at 0x8x210000 - Linux version 2.4.10-pre6 (...) (gcc version 3.1-stdsh-010931) #3 Thu Sep 27 11:04:23 BST 2001 - + diff --git a/packages/redboot/current/doc/redboot_installing.sgml b/packages/redboot/current/doc/redboot_installing.sgml --- a/packages/redboot/current/doc/redboot_installing.sgml +++ b/packages/redboot/current/doc/redboot_installing.sgml @@ -11,75 +11,82 @@ testingCyclone IQ80310RedBoot supports both serial ports and the built-in ethernet port for communication and downloads. The default serial port settings are 115200,8,N,1. RedBoot also supports flash -management for the onboard 8MB flash. Several basic RedBoot configurations -are supported: - -RedBoot running from the board's flash boot sector. - -RedBoot running from flash address 0x40000, with ARM bootloader -in flash boot sector. - -RedBoot running from RAM with RedBoot in the flash boot sector. - - -RedBoot running from RAM with ARM bootloader in flash boot -sector. - - -A special RedBoot command: diag is -used to access a set of hardware diagnostics provided by the board manufacturer. +management for the onboard 8MB flash. + +The following RedBoot mode configurations are supported: + + + + + + Configuration + Mode + Description + File + + + + + ROM + [ROM] + RedBoot running from the board's flash boot + sector. + redboot_ROM.ecm + + + RAM + [RAM] + RedBoot running from RAM with RedBoot in the + flash boot sector. + redboot_RAM.ecm + + + ROMA + [ROM] + RedBoot running from flash address 0x40000, with + ARM bootloader in flash boot sector. + redboot_ROMA.ecm + + + RAMA + [RAM] + RedBoot running from RAM with ARM bootloader in + flash boot sector. + redboot_RAMA.ecm + + + + Initial Installation Method -The board manufacturer provides a DOS application which is capable of -programming the flash over the PCI bus, and this is required for initial installations -of RedBoot. Please see the board manual for information on using this utility. -In general, the process involves programming one of the two flash based RedBoot -configurations to flash. The RedBoot which runs from the flash boot sector -should be programmed to flash address 0x00000000. RedBoot that has been configured -to be started by the ARM bootloader should be programmed to flash address -0x00004000. -Four sets of prebuilt files are provided in a tarball and zip format. -Each set corresponds to one of the four supported configurations and includes -an ELF file (.elf), a binary image (.bin), and an S-record file (.srec). -For RedBoot running from the flash boot sector: -bins/cyclone-rom.bin -bins/cyclone-rom.elf -bins/cyclone-rom.srec - - -For RedBoot running from flash address 0x40000: -bins/cyclone-roma.bin -bins/cyclone-roma.elf -bins/cyclone-roma.srec - - -For RedBoot running from RAM with RedBoot in the flash boot sector: -bins/cyclone-ram.bin -bins/cyclone-ram.elf -bins/cyclone-ram.srec - - -For RedBoot running from RAM with ARM bootloader in the flash boot sector: -bins/cyclone-rama.bin -bins/cyclone-rama.elf -bins/cyclone-rama.srecInitial installations deal with the -flash-based RedBoots. Installation and use of RAM based RedBoots is documented -elsewhere. + +The board manufacturer provides a DOS application which is +capable of programming the flash over the PCI bus, and this is +required for initial installations of RedBoot. Please see the board +manual for information on using this utility. In general, the process +involves programming one of the two flash based RedBoot images to +flash. The ROM mode RedBoot (which runs from the flash boot sector) +should be programmed to flash address 0x00000000. The ROMA RedBoot +mode (which is started by the ARM bootloader) should be programmed to +flash address 0x00004000. + + To install RedBoot to run from the flash boot sector, use the manufacturer's -flash utility to install the bins/cyclone-rom.bin image at address zero. +flash utility to install the ROM mode image at address zero. To install RedBoot to run from address 0x40000 with the ARM bootloader in the flash boot sector, use the manufacturer's flash utility to install -the bins/cyclone-roma.bin image at address 0x40000. +the ROMA mode image at address 0x40000. + After booting the initial installation of RedBoot, this warning may be printed: flash configuration checksum error or invalid key This is normal, and indicates that the flash must be configured for use by RedBoot. Even if the above message is not printed, it may be a good idea to reinitialize the flash anyway. Do this with the fis command: RedBoot> fis init -About to initialize [format] flash image system - continue (y/n)? y +About to initialize [format] flash image system - continue (y/n)? y *** Initialize flash Image System Warning: device contents not erased, some blocks may not be usable ... Unlock from 0x007e0000-0x00800000: . @@ -99,6 +106,11 @@ Followed by the fconfig command: ... Erase from 0x007c0000-0x007e0000: . ... Program from 0xa0013018-0xa0013418 at 0x007c0000: . ... Lock from 0x007c0000-0x007e0000: . + +When later updating RedBoot in situ, it is important to +use a matching ROM and RAM mode pair of images. So use either RAM/ROM +or RAMA/ROMA images. Do not mix them. + Error codes @@ -118,39 +130,10 @@ address 0x40000. RedBoot is selected by positions are used by the ARM firmware and RedBoot will not be started. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -ARM bootloader in flash boot sector --f 0x40000 --b 0xa0100000 --l 0x40000 -RedBoot in flash boot sector --f 0 --b 0xa0100000 --l 0x40000 - - -Updating the secondary RedBoot image -ARM bootloader in flash boot sector --f 0x80000 --b 0xa0020000 --r 0xa0020000 --l 0x40000 -RedBoot in flash boot sector --f 0x40000 --b 0xa0020000 --r 0xa0020000 --l 0x40000 - - Special RedBoot Commands -A special RedBoot command, diag, is used to access a set of hardware -diagnostics provided by the board manufacturer. To access the diagnostic menu, -enter diag at the RedBoot prompt: +A special RedBoot command, diag, is used to +access a set of hardware diagnostics provided by the board +manufacturer. To access the diagnostic menu, enter diag at the RedBoot prompt: RedBoot> diag Entering Hardware Diagnostics - Disabling Data Cache! @@ -204,31 +187,22 @@ item may be used to set the board ethern Rebuilding RedBoot -The build process is nearly identical for the four supported configurations. -Assuming that the provided RedBoot source tree is located in the current directory -and that we want to build a RedBoot that runs from the flash boot sector, -the build process is: % export TOPDIR=`pwd` -% export ECOS_REPOSITORY=\ - ${TOPDIR}/src/ecos-monitors/redboot-DATE-intel/packages -% mkdir ${TOPDIR}/build -% cd ${TOPDIR}/build -% ecosconfig new iq80310 redboot -% ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/iq80310/VERSION/misc/redboot_ROM.ecm -% ecosconfig tree -% makeIf a different configuration is desired, -simply use the above build process but substitute an alternate configuration -file for the ecosconfig import command, e.g.: -For a RedBoot that runs from flash address 0x40000 with the ARM booloader -in the flash boot sector, use: % ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/iq80310/VERSION/misc/redboot_ROMA.ecmFor -a RedBoot which runs from RAM with RedBoot located in the flash boot sector, -use:% ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/iq80310/VERSION/misc/redboot_RAM.ecmFor -a RedBoot which runs from RAM with ARM bootloader located in the flash boot -sector, use: % ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/iq80310/VERSION/misc/redboot_RAMA.ecm + +These shell variables provide the platform-specific information +needed for building RedBoot according to the procedure described in +: + +export TARGET=iq80310 +export ARCH_DIR=arm +export PLATFORM_DIR=iq80310 + + + +The names of configuration files are listed above with the +description of the associated modes. + + Interrupts RedBoot uses an interrupt vector table which is located at address 0xA000A004. @@ -363,19 +337,11 @@ 0xd0000000 - 0xd0000fff Y N first 4k p 0xf0000000 - 0xffffffff N N 80200 Internal Registers -Resource Usage -The standalone flash based RedBoot image (no ARM bootloader) occupies -flash addresses 0x00000000 - 0x0003ffff. -The flash based RedBoot configured to be booted by the ARM bootloader -occupies flash addresses 0x00040000 - 0x0007ffff. Both of these also reserve -RAM (0xa0000000 - 0xa001ffff) for RedBoot runtime uses. -Both RAM based RedBoot configurations are designed to run from RAM at -addresses 0xa0020000 - 0xa005ffff. RAM addresses from 0xa0060000 to the end -of RAM are available for general use, such as a temporary scratchpad for downloaded -images before they are written to flash. +Platform Resource Usage The external timer is used as a polled timer to provide timeout support for networking and XModem file transfers. + Intel IQ80321 @@ -386,55 +352,59 @@ testingIntel IQ80321RedBoot supports the serial port and the built-in ethernet port for communication and downloads. The default serial port settings are 115200,8,N,1. RedBoot also supports flash -management for the onboard 8MB flash. Several basic RedBoot configurations -are supported: - -RedBoot running from the board's flash boot sector. - -RedBoot running from RAM with RedBoot in the flash boot sector. +management for the onboard 8MB flash. + +The following RedBoot mode configurations are supported: + + + + + + Configuration + Mode + Description + File + + + + + ROM + [ROM] + RedBoot running from the board's flash boot + sector. + redboot_ROM.ecm + + + RAM + [RAM] + RedBoot running from RAM with RedBoot in the + flash boot sector. + redboot_RAM.ecm + + + + - - -A special RedBoot command: diag is -used to access a set of hardware diagnostics. - + + Initial Installation Method The board manufacturer provides a DOS application which is capable of programming the flash over the PCI bus, and this is required for initial installations of RedBoot. Please see the board manual for information on using this utility. -In general, the process involves programming the flash based RedBoot to flash. -RedBoot should be programmed to flash address 0x00000000 using the DOS utility. +In general, the process involves programming the ROM mode RedBoot +image to flash. RedBoot should be programmed to flash address +0x00000000 using the DOS utility. -Two sets of prebuilt files are provided in a tarball and zip format. -Each set corresponds to one of the supported configurations and includes -an ELF file (.elf), a binary image (.bin), and an S-record file (.srec). -For RedBoot running from the flash boot sector: -loaders/iq80321/iq80321-rom.bin -loaders/iq80321/iq80321-rom.elf -loaders/iq80321/iq80321-rom.srec - -For RedBoot running from RAM with RedBoot in the flash boot sector: -loaders/iq80321/iq80321-ram.bin -loaders/iq80321/iq80321-ram.elf -loaders/iq80321/iq80321-ram.srec - -Initial installations deal with the -flash-based RedBoots. Installation and use of RAM based RedBoots is documented -elsewhere. - To install RedBoot to run from the flash boot sector, use the manufacturer's -flash utility to install the -loaders/iq80321/iq80321-rom.bin -image at address zero. - + After booting the initial installation of RedBoot, this warning may be printed: flash configuration checksum error or invalid key This is normal, and indicates that the flash must be configured for use by RedBoot. Even if the above message is not printed, it may be a good idea to reinitialize the flash anyway. Do this with the fis command: RedBoot> fis init -About to initialize [format] FLASH image system - continue (y/n)? y +About to initialize [format] FLASH image system - continue (y/n)? y *** Initialize FLASH Image System Warning: device contents not erased, some blocks may not be usable ... Unlock from 0xf07e0000-0xf0800000: . @@ -566,30 +536,10 @@ A1 -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: --f 0xf0000000 --b 0x100000 --l 0x40000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot image, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: --f 0xf0040000 --b 0x20000 --r 0x20000 --l 0x40000 - - Special RedBoot Commands -A special RedBoot command, diag, is used to access a set of hardware -diagnostics. To access the diagnostic menu, enter diag at the RedBoot prompt: +A special RedBoot command, diag, is used to +access a set of hardware diagnostics. To access the diagnostic menu, +enter diag at the RedBoot prompt: RedBoot> diag Entering Hardware Diagnostics - Disabling Data Cache! @@ -622,11 +572,11 @@ the user will be prompted to enter the b size. The numbers must be in hex with no leading “0x” -Enter the menu item number (0 to quit): 1 - -Base address of memory to test (in hex): 100000 - -Size of memory to test (in hex): 200000 +Enter the menu item number (0 to quit): 1 + +Base address of memory to test (in hex): 100000 + +Size of memory to test (in hex): 200000 Testing memory from 0x00100000 to 0x002fffff. @@ -676,11 +626,11 @@ the current contents are invalid. In any user to enter a six byte ethernet MAC address into the serial EEPROM. -Enter the menu item number (0 to quit): 6 +Enter the menu item number (0 to quit): 6 Current MAC address: 00:80:4d:46:00:02 -Enter desired MAC address: 00:80:4d:46:00:01 +Enter desired MAC address: 00:80:4d:46:00:01 Writing to the Serial EEPROM... Done ******** Reset The Board To Have Changes Take Effect ******** @@ -737,25 +687,21 @@ This should prevent all external bus acc Rebuilding RedBoot -The build process is nearly identical for the supported configurations. -Assuming that the provided RedBoot source tree is located in the current directory -and that we want to build a RedBoot that runs from the flash boot sector, -the build process is: % export TOPDIR=`pwd` -% export ECOS_REPOSITORY=\ - ${TOPDIR}/src/ecos-monitors/redboot-DATE-intel/packages -% mkdir ${TOPDIR}/build -% cd ${TOPDIR}/build -% ecosconfig new iq80321 redboot -% ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/xscale/iq80321/VERSION/misc/redboot_ROM.ecm -% ecosconfig tree -% makeIf a RedBoot that runs from RAM is desired, -simply use the above build process but substitute an alternate configuration -file for the ecosconfig import command, e.g.: -% ecosconfig import \ - ${ECOS_REPOSITORY}/hal/arm/xscale/iq80321/VERSION/misc/redboot_RAM.ecm - + +These shell variables provide the platform-specific information +needed for building RedBoot according to the procedure described in +: + +export TARGET=iq80321 +export ARCH_DIR=arm +export PLATFORM_DIR=xscale/iq80321 + + + +The names of configuration files are listed above with the +description of the associated modes. + Interrupts RedBoot uses an interrupt vector table which is located at address 0x8004. @@ -875,13 +821,7 @@ 0xfff00000 - 0xffffffff 0 0 0 Verde Me -Resource Usage -The flash based RedBoot image occupies flash addresses -0xf0000000 - 0xf003ffff and RAM addresses (0x00000000 - 0x0001ffff). -The RAM based RedBoot configuration is designed to run from RAM at -addresses 0x00020000 - 0x0005ffff. RAM addresses from 0x00060000 to the end -of RAM are available for general use, such as a temporary scratchpad for -downloaded images before they are written to flash. +Platform Resource Usage The Verde programmable timer0 is used for timeout support for networking and XModem file transfers. @@ -946,12 +886,9 @@ 0x80000000 - 0xbfffffff N N SA-1100 In 0xe0000000 - 0xe7ffffff Y Y Cache Clean -Resource Usage -The flash based RedBoot image occupies flash addresses 0x40000000 - -0x4000ffff. The RAM based RedBoot image occupies RAM addresses 0x10000 - 0x2ffff. -RAM addresses from 0x30000 to the end of RAM are available for general use -such as a temporary scratchpad for downloaded images before they are written -to flash. The SA11x0 OS timer is used as a polled timer to provide timeout +Platform Resource Usage + +The SA11x0 OS timer is used as a polled timer to provide timeout support for XModem file transfers. @@ -992,26 +929,6 @@ in: .../packages/hal/arm -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x41000000 --b 0x100000 --l 0x40000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: -f 0x41040000 --b 0x20000 --r 0x20000 --l 0x40000 - - - Communication Channels Serial, Intel PRO 10/100+ 82559 PCI ethernet card. @@ -1038,13 +955,7 @@ 0x79000000 - 0x7c0fffff N N PCI IACK/C 0x80000000 - 0xffffffff N Y PCI Memory -Resource Usage -The flash based RedBoot image occupies flash addresses 0x41000000 - -0x4103ffff. It also reserves the first 192K bytes of RAM for runtime uses. -The RAM based RedBoot image occupies RAM addresses 0x30000 - 0x5ffff. RAM -addresses from 0x60000 to the end of RAM are available for general use such -as a temporary scratchpad for downloaded images before they are written to -flash. +Platform Resource Usage Timer3 is used as a polled timer to provide timeout support for networking and XModem file transfers. @@ -1143,12 +1054,7 @@ 0xc0000000 - 0xc07fffff N Y DRAM Bank 0xe0000000 - 0xe7ffffff Y Y Cache Clean -Resource Usage -The flash based RedBoot image occupies virtual addresses 0x50000000 -- 0x5000ffff. The RAM based RedBoot image occupies virtual addresses 0x10000 -- 0x2ffff. RAM addresses from 0x30000 to the end of RAM are available for -general use such as a temporary scratchpad for downloaded images before they -are written to flash. +Platform Resource Usage The SA11x0 OS timer is used as a polled timer to provide timeout support for XModem file transfers. @@ -1188,25 +1094,6 @@ programming. device programmer. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x50000000 --b 0x60000 --l 0x40000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: -f 0x50040000 --b 0x20000 --r 0x20000 --l 0x40000 - - Special RedBoot Commands None. @@ -1252,11 +1139,7 @@ The flash based RedBoot image occupies v -Resource Usage -The RAM based RedBoot image occupies RAM addresses 0x20000 - 0x5ffff. -RAM addresses from 0x60000 to the end of RAM are available for general use -such as a temporary scratchpad for downloaded images before they are written -to flash. +Platform Resource Usage The SA11x0 OS timer is used as a polled timer to provide timeout support for network and XModem file transfers. @@ -1359,24 +1242,7 @@ ethaddr command to prin Typically, it is: 00:0d:a0:00:xx:xx where xx.xx is the hex representation of the board serial number. - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: -f 0x9dc40000 --b 0x80020000 --r 0x80020000 --l 0x40000 - - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x9dc00000 --b 0x80080000 --l 0x40000 - - + Additional commands The exec command which allows the @@ -1462,14 +1328,6 @@ 0x1e000000 - 0x1e3fffff Monitor flash 0x1f000000 - 0x1fbfffff FPGA -Resource Usage -The flash based RedBoot image occupies flash addresses 0x1fc00000 - -0x1fc1ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x00020000 - 0x0003ffff. RAM physical addresses from -0x00040000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -1549,25 +1407,6 @@ the S-record file: % % srecconv.pl -ES L -A 29 redboot_ROM The resulting file is named redboot_ROM.fl. - -Flash management - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: -f 0xBE020000 --b 0x80020000 --r 0x80020000 --l 0x20000 - - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0xBE000000 --b 0x80080000 --l 0x20000 - Additional commands @@ -1657,14 +1496,6 @@ 0xbe000000 - 0xbe3fffff N N System flas 0xbf000000 - 0xbfffffff N N Board logic FPGA -Resource Usage -The flash based RedBoot image occupies flash addresses 0xbe000000 - -0xbe01ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x00020000 - 0x0004ffff. RAM physical addresses from -0x00050000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -1695,31 +1526,6 @@ Two basic RedBoot configurations are sup Initial Installation Method Device programmer is used to program socketed flash parts. - -Flash Management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , loading the primary image into -RAM at 0x80100000. The actual numbers used with -the flags in the sample commands are then: - --f 0xbfc00000 --b 0x80100000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0xbfc20000 --b 0x80020000 --r 0x80020000 --l 0x20000 - - Additional commands @@ -1770,15 +1576,6 @@ 0x1c000000 - 0x1c0000ff PLD (board logic 0x1fc00000 - 0x1fc7ffff flash -Resource Usage -The flash based RedBoot image occupies flash addresses 0x1fc00000 - -0x1fc1ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. -RAM based RedBoot configurations are designed to run from RAM at physical -addresses 0x00020000 - 0x0003ffff. RAM physical addresses from 0x00040000 -to the end of RAM are available for general use, such as a temporary scratchpad -for downloaded images, before they are written to flash. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -1853,28 +1650,6 @@ RedBoot> fi cr RedBoot -f 0xF -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0xfe000000 --b 0x50000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0xfe020000 --b 0x20000 --r 0x20000 --l 0x20000 - - - Special RedBoot Commands None. @@ -1889,15 +1664,6 @@ 0xfe000000 - 0xfe07ffff flash (AMD29F040 0xff000000 - 0xff0fffff MPC registers -Resource Usage -The flash based RedBoot image occupies flash addresses 0xfe000000 - - 0xfe01ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x00020000 - 0x0004ffff. RAM physical addresses from -0x00050000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -1930,20 +1696,6 @@ A single RedBoot configuration is suppor -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: - --f 0xfe000000 --b 0x50000 --l 0x30000 - - - - Special RedBoot Commands None. @@ -1957,14 +1709,6 @@ 0xfe000000 - 0xfe0fffff flash (AMD29LV80 0xff000000 - 0xff0fffff MPC registers -Resource Usage -The flash based RedBoot image occupies flash addresses 0xfe000000 - - 0xfe02ffff. RedBoot also reserves RAM (0x00000000 - 0x0003ffff) for RedBoot -runtime uses. RAM physical addresses from -0x00040000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -2048,14 +1792,6 @@ 0x03ff0000 - 0x03ffffff N N Microcontro 0x01820000 - 0x0187ffff N N System flash (mirrored) -Resource Usage -The flash based RedBoot image occupies flash addresses 0x0182000 - 0x0182ffff. - -RedBoot also reserves RAM (0x00000000 - 0x0000ffff) for RedBoot runtime -uses. -RAM physical addresses from 0x00010000 to the end of RAM are available -for general use. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -2195,20 +1931,6 @@ 0x80000000 - 0x8fffffff N N SDRAM echo -Resource Usage - -The flash based RedBoot image occupies flash addresses -0x24000000 - 0x2401ffff. - - -RedBoot also reserves RAM (0x00000000 - 0x0003ffff) for RedBoot runtime -uses. If ethernet support is included, then the address range -0x00f00000 to 0x00ffffff are reserved for use by the driver. This may -be moved using the MLT. - -RAM physical addresses from 0x00040000 to 0x00efffff and from -0x00100000 to the end of SDRAM are available for general use. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this @@ -2266,16 +1988,6 @@ 0x0a000000 - 0x0bffffff APB Reference Pe 0x0c000000 - 0x0fffffff NISA Serial, Parallel and PC Card ports -Resource Usage -The flash based RedBoot image occupies flash addresses 0x04000000 - - 0x0401ffff. -RedBoot also reserves RAM (0x00000000 - 0x00007fff) for RedBoot runtime -uses. -RAM based RedBoot configurations are designed to run from RAM at physical -addresses 0x00008000 - 0x0003ffff. RAM physical addresses from 0x00040000 -to the end of RAM are available for general use, such as a temporary scratchpad -for downloaded images, before they are written to flash. - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -2432,34 +2144,6 @@ for directions. -Flash Management - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , relying on default location -and size of the image. It is also possible to explicitly specify the options -- the appropriate options for the iPAQ are: -f 0x50080000 --b 0x00020000 --r 0x00020000 --e 0x00020040 --l 0x40000When updating the image, the flash should be unlocked -before programming, and relocked afterwards. This is done with the commands: - fis unlock -f 0x50080000 -l 0x40000and -fis lock -f 0x50080000 -l 0x40000 - - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , relying on default location and -size of the image. It is also possible to explicitly specify the options - -the appropriate options for the iPAQ are: -f 0x50040000 --b 0x00100000 --l 0x40000 When updating the image, the flash should be unlocked -before programming, and relocked afterwards. This is done with the commands: - fis unlock -f 0x50040000 -l 0x40000and -fis lock -f 0x50040000 -l 0x40000 - - Additional commands The exec command which allows the loading and execution of Linux kernels, @@ -2526,17 +2210,6 @@ 0xc0000000 - 0xc1ffffff N Y DRAM Bank 0xe0000000 - 0xe7ffffff Y Y Cache Clean -Resource Usage -The flash based RedBoot image occupies flash addresses 0x50040000 - -0x5007ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at virtual addresses 0x00020000 - 0x0005ffff. RAM virtual addresses from -0x00060000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. An exception -is RAM from 0x01F70000 - 0x01FFFFFF which is reserved for use by the LCD -display. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -2603,20 +2276,6 @@ FLASH: 0x50000000 - 0x51000000, 128 bloc -Flash Management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , relying on default location and -size of the image. It is also possible to explicitly specify the options - -the appropriate options for the CerfCube are: -f 0x50000000 --b 0x00100000 --l 0x40000 When updating the image, the flash should be unlocked -before programming, and relocked afterwards. This is done with the commands: - fis unlock -f 0x50000000 -l 0x20000and -fis lock -f 0x50000000 -l 0x20000 - - Additional commands The exec command which allows the loading and execution of Linux kernels, @@ -2671,17 +2330,7 @@ 0x80000000 - 0xbfffffff N N SA-1110 In 0xc0000000 - 0xc1ffffff N Y DRAM Bank 0: 32Mb 0xe0000000 - 0xe7ffffff Y Y Cache Clean - - -Resource Usage -The flash based RedBoot image occupies flash addresses 0x50000000 - -0x5001ffff. RedBoot also reserves RAM (0x00000000 - 0x0001ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at virtual addresses 0x00020000 - 0x0005ffff. RAM virtual addresses from -0x00060000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - + Rebuilding RedBoot The instructions in should be followed. @@ -2722,37 +2371,6 @@ flash boot sector. in situ flash programming. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: - --f 0xE0000000 --b 0x40000 --l 0x40000 - - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: --f 0xE0040000 --b 0x40000 --r 0x40000 --l 0x40000 - -NOTE - -On the EDB7312, because the primary RedBoot image runs in RAM and not -FLASH, it can be updated directly without -use of the separate RAM based version. - - - - Special RedBoot Commands None. @@ -2797,19 +2415,7 @@ The flash based RedBoot image occupies v -Resource Usage - -The RAM based RedBoot image occupies RAM addresses -0x40000 - 0x7ffff. -The ROMRAM based RedBoot image (EDB7312 only) occupies RAM addresses -0x1000 - 0x3ffff. -RAM addresses start at -0x80000 -and continue up to the top of the installed -physical RAM size, less the memory reserved for MMU page tables -(0x9000 bytes) and the LCD display buffer, if enabled (0x20000 bytes). The -RAM is available for general use such as a temporary scratchpad -for downloaded images before they are written to flash. +Platform Resource Usage The EP7xxx timer #2 is used as a polled timer to provide timeout support for network and XModem file transfers. @@ -3107,12 +2713,6 @@ 0x100000 for option ROMs and the BIOS. -Resource Usage -RedBoot is loaded into RAM at address 0x2000 and reserves all RAM below -0xa0000 for its own use. RAM applications should load from address 0x100000 -upwards. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3184,12 +2784,6 @@ GDB command: -Resource Usage -The RedBoot image occupies program addresses 0x000000 - 0x00ffff -and data addresses 0x000000 - 0x00ffff. - - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3259,12 +2853,6 @@ GDB command: -Resource Usage -The RedBoot image occupies program addresses 0x00000000 - 0x0000ffff -and data addresses 0x00000000 - 0x0000ffff. - - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3298,17 +2886,6 @@ are supported: Program the ROM RedBoot image into flash using an eprom programmer. - -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x80000000 --b 0x88040000 --l 0x20000 - - Memory Maps @@ -3322,15 +2899,6 @@ 0xb8000000 - 0xb80000ff LED ON -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - - 0x8001ffff. RedBoot also reserves RAM (0x88000000 - 0x8800ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x88010000 - 0x8803ffff. RAM physical addresses from -0x88040000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3392,28 +2960,6 @@ should now see the RedBoot banner. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x80000000 --b 0x8c080000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0x80020000 --b 0x8c020000 --r 0x8c020000 --l 0x20000 - - - Special RedBoot Commands The exec command which allows the loading and execution of Linux kernels @@ -3483,15 +3029,6 @@ 0xb1800000 - 0xb1bfffff PCMCIA (MaruBun) only be changed in CDL. -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - - 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from -0x8c080000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3553,28 +3090,6 @@ should now see the RedBoot banner. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x80000000 --b 0x8c080000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0x80020000 --b 0x8c020000 --r 0x8c020000 --l 0x20000 - - - Special RedBoot Commands The exec command which allows the loading and execution of Linux kernels @@ -3648,15 +3163,6 @@ 0xb8000000 - 0xbbffffff PCMCIA (MaruBun) only be changed in CDL. -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - - 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from -0x8c080000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3715,28 +3221,6 @@ should now see the RedBoot banner. -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x80000000 --b 0x8c080000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0x80020000 --b 0x8c020000 --r 0x8c020000 --l 0x20000 - - - Special RedBoot Commands The exec command which allows the loading and execution of Linux kernels @@ -3807,15 +3291,6 @@ 0xbe240000 - 0xbe27ffff PCI IO space only be changed in CDL. -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - - 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from -0x8c080000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -3883,28 +3358,6 @@ the flash table with the correct address -Flash management - -Updating the primary RedBoot image -To update the primary RedBoot images, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: -f 0x80000000 --b 0x8c080000 --l 0x20000 - - -Updating the secondary RedBoot image -To update the secondary RedBoot images, follow the procedures detailed -in , but the actual numbers used -with the flags in the sample commands should be: - --f 0x80020000 --b 0x8c020000 --r 0x8c020000 --l 0x20000 - - - Special RedBoot Commands The exec command which allows the loading and execution of Linux kernels @@ -3974,15 +3427,6 @@ 0xb8000000 - 0xbbffffff PCMCIA (MaruBun) -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - - 0x8001ffff. RedBoot also reserves RAM (0x8c000000 - 0x8c01ffff) for RedBoot -runtime uses. RAM based RedBoot configurations are designed to run from RAM -at physical addresses 0x8c020000 - 0x8c07ffff. RAM physical addresses from -0x8c080000 to the end of RAM are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are @@ -4070,28 +3514,17 @@ Copyright (C) 2000, 2001, Red Hat, Inc. RAM: 0x02000000-0x02080000, 0x020116d8-0x0207fd00 available FLASH: 0x01010000 - 0x01020000, 256 blocks of 0x00000100 bytes each. -RedBoot> load -m ymodem -b 0x02040000 +RedBoot> load -m ymodem -b %{FREEMEMLO} Use minicom to send the file redboot_ROMRAM.srec via YModem. -RedBoot> fi wr -f 0x01010000 -b 0x02040000 -l 0xe000 +RedBoot> fi wr -f 0x01010000 -b %{FREEMEMLO} -l 0xe000 Set switch SW1 to "upper mem", press the "reset" pushbutton and RedBoot should come up on the board. -Flash management - -Updating the RedBoot image in flash - -Since the primary RedBoot runs from RAM, it can be used to update itself directly. -Simply follow the steps above, starting with a connection to RedBoot running on -the board. - - - - Special RedBoot Commands None. @@ -4111,12 +3544,6 @@ The flash based RedBoot image occupies v -Resource Usage -The RAM based RedBoot image occupies RAM addresses 0x02020000 - 0x0203ffff. -RAM addresses from 0x02040000 to the end of RAM are available for general use -such as a temporary scratchpad for downloaded images before they are written -to flash. - Rebuilding RedBoot The instructions in should be followed. The values for PLATFORM_DIR on this platform is @@ -4421,18 +3848,6 @@ 0x8C001000 - Linux command l therefore be aligned to a 0xFF000000 mask. -Resource Usage -The flash based RedBoot image occupies flash addresses 0x80000000 - 0x8001ffff. RedBoot also -reserves RAM (0x90000000 - 0x9001ffff) for RedBoot runtime uses. RAM based RedBoot configurations -are designed to run from RAM at physical addresses 0x90000000 - 0x9001ffff. RAM physical addresses -from 0x90050000 to the end of RAM are available for general use, such as a temporary scratchpad for -downloaded images, before they are written to flash. - -NOTE -The location at which RedBoot can be started is highly restricted due to the way in which the -address of the Trap Vector Table is specified to the CPU. - - Rebuilding RedBoot The instructions in should be followed. The values for TARGET, ARCH_DIR and PLATFORM_DIR on this platform are “asb2305”, “mn10300” @@ -4720,41 +4135,6 @@ while pressing the SPACE key. --> - -Flash management - -Updating the RedBoot image - Since the RedBoot image is a ROMRAM-startup -type, it is not necessary to load and run the RAM startup RedBoot -image to update the image in flash. Doing so causes no harm though - -but ignoring the step saves some time. - - -To update the primary RedBoot image, follow the procedures -detailed in , but let RedBoot -find the correct flash address (the -f option) since this is different -between the bootmonitor configurations. If -specifying it, be sure to get it right - the actual numbers used with -the flags in the sample commands should for a RedBoot image configured -to be the primary bootmonitor be: - --f 0x60000000 --b 0x100000 --l 0x40000 - - - - - - Special RedBoot Commands @@ -4830,19 +4210,6 @@ 0xf0000000 - 0xffffffff N N SDRAM (unc -Resource Usage -The RAM based RedBoot image occupies RAM addresses -0x40000 - 0x7ffff. -The flash based RedBoot image occupies RAM addresses -0x00000000 - 0x0003ffff. -RAM addresses from 0x80000 to the end of RAM are available for general use -such as a temporary scratchpad for downloaded images before they are written -to flash. -If configured to use the LCD screen, additional DRAM from -0x01f80000 - 0x01ffffff -is used for the LCD frame buffer. - - Rebuilding RedBoot The instructions in should be followed. The values for ARCH_DIR and PLATFORM_DIR on this platform are @@ -4887,28 +4254,6 @@ before reprogramming the FLASH. (AMD 29F040). The board as delivered is configured for a 512K EPROM. To install a FLASH ROM, Jumpers J30, J31 and J36 need to be changed as described in the board's User Manual. - - -Since RedBoot for this board relocates itself from ROM to RAM at -startup, it is not necessary to run a secondary RAM based version of -RedBoot to update the main FLASH image. Instead this can be done from -the primary version of RedBoot. - - - -Updating the primary RedBoot image -To update the primary RedBoot image, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: - --b 0x80100000 - -Flash locking and unlocking is not required. -Note that these values are inferred when updating the RedBoot image once -the fis create has been run. - - - @@ -4969,22 +4314,6 @@ 0xCxxxxxxx. -Resource Usage - - -The RedBoot image occupies flash addresses 0x1fc00000 - 0x1fc1ffff. To -execute it copies itself out of there to RAM at 0x80000000. RedBoot -reserves 1MB of RAM from 0x80000000 to 0x800FFFFF for its own use. -The top 1MB of RAM from 0x81F00000 to 0x81FFFFFF is reserved for use -by the PCI Ethernet device. RAM based RedBoot configurations are -designed to run from RAM at virtual addresses 0x80100000 - -0x8011ffff. RAM virtual addresses from 0x80020000 to the start of the -PCI window are available for general use, such as a temporary -scratchpad for downloaded images, before they are written to flash. - - - - Ethernet Driver @@ -5073,21 +4402,6 @@ version into the FLASH device. Complete separately. - -Updating the primary RedBoot image -To update the primary RedBoot image, follow the procedures detailed -in , but the actual numbers used with -the flags in the sample commands should be: - --f 0xFF000000 --b 0x100000 --l 0x40000 - -Note that these values are inferred when updating the RedBoot image once -the fis create has been run. - - - @@ -5130,19 +4444,6 @@ is supported at this time. -Resource Usage - - -The RedBoot image occupies flash addresses 0xFF000000 - 0xFF03FFFF. To -execute it copies itself out of there to RAM at 0x03E00000. RedBoot -reserves memory from 0x00000000 to 0x0001FFFF for its own use. -User programs can use memory from 0x00020000 to 0x03DFFFFF. -RAM based RedBoot configurations are -designed to run from RAM at 0x00020000. - - - - Rebuilding RedBoot diff --git a/packages/redboot/current/doc/redboot_rebuilding.sgml b/packages/redboot/current/doc/redboot_rebuilding.sgml --- a/packages/redboot/current/doc/redboot_rebuilding.sgml +++ b/packages/redboot/current/doc/redboot_rebuilding.sgml @@ -3,163 +3,164 @@ Introduction rebuilding RedBoot -RedBootrebuildingIn -normal circumstances it is only necessary to rebuild RedBoot if it has been -modified, for example if you have extended the command set or applied patches. -See the Getting Started with eCos document, which provides -information about the portability and extendability of RedBoot in an eCos -environment. -Most platform HALs provide configuration export files. Before proceding -with the following procedures, see first, which may simplify the process -for your platform. - ecosconfigRedBoot is configured -and built using configuration technology based on Configuration Description -Language (CDL). The detailed instructions for building the command-line tool -ecosconfig on Linux can be found in host/README. For example: - mkdir $TEMP/redboot-build -cd $TEMP/redboot-build -$ECOSDIR/host/configure --prefix=$TEMP/redboot-build --with-tcl=/usr -make -The simplest version of RedBoot can be built by setting the -environment variable ECOS_REPOSITORY to point at the eCos/RedBoot source -tree, and then typing: -ecosconfig new TARGET redboot -ecosconfig tree -makewhere TARGET is the eCos name for the desired platform, -for example assabet. You will need to -have set the environment variable ECOS_REPOSITORY to point at the -eCos/RedBoot source tree. Values of TARGET for each board are given in the -specific installation details for each board in -. +RedBootrebuilding +RedBoot is built as an application on top of eCos. The makefile rules +for building RedBoot are part of the eCos CDL package, so it's +possible to build eCos from the Configuration +Tool, as well as from the command line using +ecosconfig. + +Building RedBoot requires only a few steps: selecting the +platform and the RedBoot template, importing a platform specific +configuration file, and finally starting the build. + +The platform specific configuration file makes sure the settings +are correct for building RedBoot on the given platform. Each platform +should provide at least two of these configuration files: +redboot_RAM.ecm for a RAM mode RedBoot +configuration and redboot_ROM.ecm or +redboot_ROMRAM.ecm for a ROM or ROMRAM mode +RedBoot configuration. There may be additional +configuration files according to the requirements of the particular +platform. + +The RedBoot build process results in a number of files in the +install bin directory. The ELF +file redboot.elf is the pricipal +result. Depending on the platform CDL, there will also be generated +versions of RedBoot in other file formats, such as +redboot.bin (binary format, good when doing an +update of a primary RedBoot image, see ), redboot.srec +(Motorola S-record format, good when downloading a RAM mode image for +execution), and redboot.img (stripped ELF format, +good when downloading a RAM mode image for execution, smaller than the +.srec file). Some platforms may provide additional file formats and +also relocate some of these files to a +particular address making them more suitable for downloading using a +different boot monitor or flash programming tools. + +The platform specific information in should be consulted, as there may +be other special instructions required to build RedBoot for particular +platforms. + + +Rebuilding RedBoot using <application>ecosconfig</application> + +To rebuild RedBoot using the +ecosconfig tool, create a temporary +directory for building RedBoot, name it according to the desired +configuration of RedBoot, here RAM: + +$ mkdir /tmp/redboot_RAM +$ cd /tmp/redboot_RAM + + + +Create the build tree according to the chosen platform, here +using the Hitachi Solution Engine 7751 board as +an example: +It is assumed that the environment variable +ECOS_REPOSITORY points to the eCos/RedBoot source tree. + +$ ecosconfig new se7751 redboot +U CYGPKG_HAL_SH_7750, new inferred value 0 +U CYGPKG_HAL_SH_7751, new inferred value 1 +U CYGHWR_HAL_SH_IRQ_USE_IRQLVL, new inferred value 1 +U CYGSEM_HAL_USE_ROM_MONITOR, new inferred value 0 +U CYGDBG_HAL_COMMON_CONTEXT_SAVE_MINIMUM, new inferred value 0 +U CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS, new inferred value 1 +U CYGFUN_LIBC_STRING_BSD_FUNCS, new inferred value 0 +U CYGPKG_NS_DNS_BUILD, new inferred value 0 + +Replace the platform name ("se7751") with the appropriate name for the +chosen platform. -The above command sequence would build a very simple version of -RedBoot, and would not include, for example, networking, FLASH or Compact Flash -Ethernet support on targets that supported those. Such features could -be included with the following commands: -ecosconfig new TARGET redboot -ecosconfig add flash -ecosconfig add pcmcia net_drivers cf_eth_drivers +Then import the appropriate platform RedBoot configuration file, +here for RAM configuration: + +$ ecosconfig import ${ECOS_REPOSITORY}/hal/sh/se7751/current/misc/redboot_RAM.ecm +$ ecosconfig tree + +Replace architecture ("sh"), platform ("se7751") and version +("current") with those appropriate for the chosen platform and the +version number of its HAL package. Also replace the configuration name +("redboot_RAM.ecm") with that of the appropriate configuration file. + + +RedBoot can now be built: + +$ make + + + +The resulting RedBoot files will be in the associated +install directory, in this example, ./install/bin. + +In each platform's +details are described in the form of shell variables. Using those, +the steps to build RedBoot are: + +export REDBOOT_CFG=redboot_ROM +export VERSION=current +mkdir /tmp/${REDBOOT_CFG} +cd /tmp/${REDBOOT_CFG} +ecosconfig new ${TARGET} redboot +ecosconfig import ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm ecosconfig tree -make -In practice, most platform HALs include configuration export files, -described in , to ensure that -the correct configuration of RedBoot -has been chosen to avoid needing to worry about which extra packages -to add. -The above commands would build a version of RedBoot -suitable for testing. In particular, the result will run from RAM. Since RedBoot -normally needs to be installed in ROM/flash, type the following: -cat >RedBoot_ROM.ecm <<EOF -cdl_component CYG_HAL_STARTUP { - user_value ROM -}; -EOF -ecosconfig import RedBoot_ROM.ecm -ecosconfig tree -make -This set of commands will adjust the configuration to be ROM oriented. +make + +To build for another configuration, simply change the +REDBOOT_CFG definition accordingly. Also +make sure the VERSION variable matches the +version of the platform package. -Each of these command sequences creates multiple versions of RedBoot -in different file formats. The choice of which file to use will depend upon -the actual target hardware and the tools available for programming ROM/flash. -The files produced (typically) are: -install/bin/redboot.elf This is the -complete version of RedBoot, represented in ELF format. It is most useful -for testing with tools such as embedded ICE, or other debug tools. -install/bin/redboot.srec This version -has been converted to Motorola S-record format. -install/bin/redboot.bin This version -has been flattened; that is, all formatting information removed and just the -raw image which needs to be placed in ROM/flash remains. -The details of putting the RedBoot code into ROM/flash are target specific. -Once complete, the system should come up with the RedBoot prompt. For example, -the version built using the commands above looks like: RedBoot(tm) debug environment [ROM] -Red Hat certified release, version R1.xx - built 07:54:25, Oct 16 2000 -Platform: Assabet development system (StrongARM 1110) -Copyright (C) 2000, Red Hat, Inc. -RAM: 0x00000000-0x02000000 -flash: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes ea. -Socket Communications, Inc: Low Power Ethernet CF Revision C -5V/3.3V 08/27/98 -IP: 192.168.1.29, Default server: 192.168.1.101 -RedBoot> - -Configuration export files -configuration export filesTo -help with rebuilding RedBoot from source, some platforms HALs provide configuration -export files. First locate the configuration export files for your platform -in the eCos source repository. The RAM and ROM startup configuration exports -can usually be found in a directory named "misc" in the platform HAL in the -eCos source repository, named: misc/redboot_RAM.ecm -misc/redboot_ROM.ecm - -Making RedBoot for RAM startup - -Throughout the following instructions, several environmental variables -are referred to: - -$REDBOOTDIR -Full path to the toplevel RedBoot source release. - -$BUILDDIR -Full path to where RedBoot will be built, -e.g. redboot.RAM. - -$ECOS_REPOSITORY -Full path to the RedBoot package source. Typically, this should -be $REDBOOTDIR/packages. - -$TARGET -e.g.atlas_mips32_4kc. -$ARCH_DIR -The directory for the architecture, e.g. mips. - -$PLATFORM_DIR -The directory for the platform, e.g. atlas. - -$VERSION -The version of the release, e.g. current. - -You must make sure these variables are correctly set in your environment -before proceeding, or the build will fail. The values for -$TARGET, $ARCH_DIR and -$PLATFORM_DIR for each board are given in the -specific installation details for each board -in . The value for -$VERSION is the name of the package subdirectories - -usually 'current' for sources checked out of CVS, or something like -'vX_Y' for a regular X.Y release. - -With the environment variables set, use the following sequence of commands to -build a RedBoot image suitable for loading into RAM: -$ mkdir $BUILDDIR -$ cd $BUILDDIR -$ ecosconfig new $TARGET redboot -$ ecosconfig import \ - ${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/redboot_RAM.ecm -$ ecosconfig tree -$ make -To build a ROM or ROMRAM version, in a different build/config directory, just -use the configuration export file redboot_ROM.ecm -or redboot_ROMRAM.ecm instead. + + + + +Rebuilding RedBoot from the <application>Configuration Tool</application> + +To rebuild RedBoot from the Configuration +Tool, open the template window (Build->Templates) and +select the appropriate Hardware target and in Packages select +"redboot". Then press OK. Depending on the platform, a number of +conflicts may need to be resolved before the build can be started; +select "Continue". + +Import the desired RedBoot configuration file from the platform HAL +(File->Import...). Depending on the platform, a number of +conflicts may need to be resolved before the build can be started; +select "Continue". For example, if the platform selected is Hitachi +SE7751 board and the RAM configuration RedBoot should be built, import +the file +hal/sh/se7751/current/misc/redboot_RAM.ecm. + +Save the configuration somewhere suitable with enough disk space +for building RedBoot (File->Save...). Choose the name according to +the RedBoot configuration, for example +redboot_RAM.ecc. + +Then start the build (Build->Library) and wait for it to +complete. The resulting RedBoot files will be in the associated +install directory, for the example this would be redboot_RAM_install/bin. + +As noted above, each platform's details are described in . Use the information provided in +the shell variables to find the configuration file - the path to it is +${ECOS_REPOSITORY}/hal/${ARCH_DIR}/${PLATFORM_DIR}/${VERSION}/misc/${REDBOOT_CFG}.ecm, +where ECOS_REPOSITORY points to the +eCos/RedBoot sources, VERSION is the +version of the package (usually "current") and +REDBOOT_CFG is the desired configuration, +e.g. redboot_RAM. -The resulting files will be, in each of the ROM, ROMRAM and RAM - startup build places: - $BUILDDIR/install/bin/redboot.bin - $BUILDDIR/install/bin/redboot.elf - $BUILDDIR/install/bin/redboot.img - $BUILDDIR/install/bin/redboot.srec -Some targets may have variations, or extra files generated in addition. - - -Platform specific instructions - -The platform specific information in -should be consulted, as there may be other special instructions -required to build RedBoot for particular boards. + Updating RedBoot @@ -172,41 +173,18 @@ on the board. In the former case, updati physically removing the part and reprogramming a new RedBoot image into it using prommer hardware. In the latter case, it is often possible to update RedBoot in situ using -Redboot's flash management commands. The process of updating RedBoot -in situ is documented in -this section. +Redboot's flash management commands. + +The process of updating RedBoot in situ is documented in this +section. For this process, it is assumed that the target is connected +to a host system and that there is a serial connection giving access +to the RedBoot CLI. For platforms with a ROMRAM mode RedBoot, skip to +. The addresses and sizes included in the below are examples only, and will differ from those you will see. This is normal and should not cause concern. - -Startup Modes - -While the RedBoot image which is used as the board's primary -boot monitor resides in flash, it may run from either flash (ROM mode) -or from RAM (ROMRAM mode). - -In ROM mode, RedBoot runs from flash memory, and the flash -commands cannot update the region of flash where the RedBoot image -resides. In order to update the RedBoot image, it is necessary to run -a different instance of RedBoot from RAM. - -In ROMRAM mode, the RedBoot image is copied to RAM when the -board is powered up or reset, and the code runs from there. The RAM -footprint is larger, but there are two advantages to make up for this: -it normally runs faster (relevant only on slower boards) and it is -able to update the flash region where the image originated -from. - -The following is a more detailed look at the necessary steps for -updating RedBoot in situ. For this process, it is assumed that the target is -connected to a host system and that there is a serial connection -giving access to the RedBoot CLI. For platforms with a ROMRAM -mode RedBoot, skip to . - - Load and start a RedBoot RAM instance There are a number of choices here. The basic case is where a RAM @@ -242,9 +220,6 @@ recognized by RedBoot). RedBoot> fis unlock RedBoot[RAM] ... Unlock from 0x00000000-0x00020000: .. RedBoot> fis create RedBoot[RAM] -No memory address set. -Inferring base 0x06020000, length 0x20000, image size 0x169c8, entry 0x060213c0 - - continue (y/n)? y An image named 'RedBoot[RAM]' exists - continue (y/n)? y * CAUTION * about to program 'RedBoot[RAM]' at 0x00020000..0x000369c7 from 0x06020000 - continue (y/n)?y @@ -277,7 +252,7 @@ About to initialize [format] FLASH image -It is important to understand that the presense of a correctly +It is important to understand that the presence of a correctly initialized FIS directory allows RedBoot to automatically determine the flash parameters. Additionally, executing the steps below as stated without loading other data or using other flash commands (than @@ -287,6 +262,14 @@ the risk of potential critical mistakes still always possible to explicitly specify parameters, and indeed override these, but it is not advised. +If the new RedBoot image has grown beyond the slot in +flash reserved for it, it is necessary to change the RedBoot +configuration option CYGBLD_REDBOOT_MIN_IMAGE_SIZE so the FIS is +created with adequate space reserved for RedBoot images. In this case, +it is necessary to re-initialize the FIS directory as described above, +using a RAM mode RedBoot compiled with the updated +configuration. + Using the load command, download the new flash based image from the host, relocating the image to RAM:: RedBoot> load -r -b %{FREEMEMLO} redboot_ROM.bin @@ -333,8 +316,6 @@ by RedBoot). RedBoot> fis unlock RedBoot ... Unlock from 0x00000000-0x00020000: .. RedBoot> fis create RedBoot -Inferring base 0x06046800, length 0x20000, image size 0x1c7e8, entry 0x00000000 - - continue (y/n)? y An image named 'RedBoot' exists - continue (y/n)? y * CAUTION * about to program 'RedBoot' at 0x00000000..0x0001c7e7 from 0x06046800 - continue (y/n)? y diff --git a/packages/redboot/current/include/elf.h b/packages/redboot/current/include/elf.h --- a/packages/redboot/current/include/elf.h +++ b/packages/redboot/current/include/elf.h @@ -37,7 +37,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/fis.h b/packages/redboot/current/include/fis.h --- a/packages/redboot/current/include/fis.h +++ b/packages/redboot/current/include/fis.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/flash_config.h b/packages/redboot/current/include/flash_config.h --- a/packages/redboot/current/include/flash_config.h +++ b/packages/redboot/current/include/flash_config.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/fs/disk.h b/packages/redboot/current/include/fs/disk.h --- a/packages/redboot/current/include/fs/disk.h +++ b/packages/redboot/current/include/fs/disk.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/fs/e2fs.h b/packages/redboot/current/include/fs/e2fs.h --- a/packages/redboot/current/include/fs/e2fs.h +++ b/packages/redboot/current/include/fs/e2fs.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/fs/ide.h b/packages/redboot/current/include/fs/ide.h --- a/packages/redboot/current/include/fs/ide.h +++ b/packages/redboot/current/include/fs/ide.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/net/bootp.h b/packages/redboot/current/include/net/bootp.h --- a/packages/redboot/current/include/net/bootp.h +++ b/packages/redboot/current/include/net/bootp.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/net/http.h b/packages/redboot/current/include/net/http.h new file mode 100644 --- /dev/null +++ b/packages/redboot/current/include/net/http.h @@ -0,0 +1,68 @@ +//========================================================================== +// +// net/http.h +// +// Stand-alone HTTP (client) support for RedBoot +// +//========================================================================== +//####ECOSGPLCOPYRIGHTBEGIN#### +// ------------------------------------------- +// This file is part of eCos, the Embedded Configurable Operating System. +// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +// +// eCos is free software; you can redistribute it and/or modify it under +// the terms of the GNU General Public License as published by the Free +// Software Foundation; either version 2 or (at your option) any later version. +// +// eCos is distributed in the hope that it will be useful, but WITHOUT ANY +// WARRANTY; without even the implied warranty of MERCHANTABILITY or +// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +// for more details. +// +// You should have received a copy of the GNU General Public License along +// with eCos; if not, write to the Free Software Foundation, Inc., +// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// As a special exception, if other files instantiate templates or use macros +// or inline functions from this file, or you compile this file and link it +// with other works to produce a work based on this file, this file does not +// by itself cause the resulting work to be covered by the GNU General Public +// License. However the source code for this file must still be made available +// in accordance with section (3) of the GNU General Public License. +// +// This exception does not invalidate any other reasons why a work based on +// this file might be covered by the GNU General Public License. +// +// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +// at http://sources.redhat.com/ecos/ecos-license/ +// ------------------------------------------- +//####ECOSGPLCOPYRIGHTEND#### +//========================================================================== +//#####DESCRIPTIONBEGIN#### +// +// Author(s): gthomas +// Contributors: gthomas +// Date: 2002-05-22 +// Purpose: +// Description: +// +// This code is part of RedBoot (tm). +// +//####DESCRIPTIONEND#### +// +//========================================================================== + +#ifndef _HTTP_H_ +#define _HTTP_H_ + +extern int http_stream_open(char *file, struct sockaddr_in *server, int *err); +extern int http_stream_read(char *buf, int len, int *err); +extern int http_stream_close(int *err); +extern char *http_error(int err); + +#define HTTP_NOERR 0 // No error +#define HTTP_BADHDR 1 // Invalid HTTP header (response) +#define HTTP_OPEN 2 // Problems opening connection +#define HTTP_IO 3 // Misc I/O problems + +#endif // _HTTP_H_ diff --git a/packages/redboot/current/include/net/net.h b/packages/redboot/current/include/net/net.h --- a/packages/redboot/current/include/net/net.h +++ b/packages/redboot/current/include/net/net.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -505,6 +505,12 @@ extern int __udp_recvfrom(char *buf, int extern void __tcp_poll(void); /* + * Initiate outgoing connection, waiting for at most timeout seconds. + */ +extern int __tcp_open(tcp_socket_t *s, struct sockaddr_in *host, + word port, int timeout, int *err); + +/* * Set up a listening socket on the given port. * Does not block. */ @@ -521,7 +527,6 @@ extern void __tcp_so_reuseaddr(tcp_socke */ extern void __tcp_drain(tcp_socket_t *s); - /* * Initiate connection close. */ @@ -546,6 +551,13 @@ extern int __tcp_read(tcp_socket_t *s, c */ extern int __tcp_write(tcp_socket_t *s, char *buf, int len); +/* + * Write up to 'len' bytes, blocking until sent (not ACK'd). + * Returns number of bytes written. + * If connection is closed, returns -1. + */ +extern int __tcp_write_block(tcp_socket_t *s, char *buf, int len); + /* * The following are a higher-level tcp socket interface. diff --git a/packages/redboot/current/include/net/tftp.h b/packages/redboot/current/include/net/tftp.h --- a/packages/redboot/current/include/net/tftp.h +++ b/packages/redboot/current/include/net/tftp.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //####BSDCOPYRIGHTBEGIN#### diff --git a/packages/redboot/current/include/net/tftp_support.h b/packages/redboot/current/include/net/tftp_support.h --- a/packages/redboot/current/include/net/tftp_support.h +++ b/packages/redboot/current/include/net/tftp_support.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/redboot.h b/packages/redboot/current/include/redboot.h --- a/packages/redboot/current/include/redboot.h +++ b/packages/redboot/current/include/redboot.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/include/sib.h b/packages/redboot/current/include/sib.h --- a/packages/redboot/current/include/sib.h +++ b/packages/redboot/current/include/sib.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/alias.c b/packages/redboot/current/src/alias.c --- a/packages/redboot/current/src/alias.c +++ b/packages/redboot/current/src/alias.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -71,7 +71,7 @@ lookup_alias(char *alias, char *alias_bu diag_sprintf(alias_buf,"%p", ((CYG_ADDRWORD)user_ram_start + 0x03ff) & ~0x03ff); return alias_buf; } else if (0 == strcasecmp("FREEMEMHI", alias)) { - diag_sprintf(alias_buf,"%p", ((CYG_ADDRWORD)user_ram_end - 0x03ff) & ~0x03ff); + diag_sprintf(alias_buf,"%p", ((CYG_ADDRWORD)user_ram_end) & ~0x03ff); return alias_buf; } diff --git a/packages/redboot/current/src/crc.c b/packages/redboot/current/src/crc.c --- a/packages/redboot/current/src/crc.c +++ b/packages/redboot/current/src/crc.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/decompress.c b/packages/redboot/current/src/decompress.c --- a/packages/redboot/current/src/decompress.c +++ b/packages/redboot/current/src/decompress.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/flash.c b/packages/redboot/current/src/flash.c --- a/packages/redboot/current/src/flash.c +++ b/packages/redboot/current/src/flash.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -595,7 +595,7 @@ fis_create(int argc, char *argv[]) bool no_copy = false; void *err_addr; struct fis_image_desc *img = NULL; - bool slot_found, defaults_assumed; + bool defaults_assumed; struct option_info opts[7]; bool prog_ok = true; @@ -636,24 +636,18 @@ fis_create(int argc, char *argv[]) (load_address_end) < (CYG_ADDRESS)ram_end) { mem_addr = load_address; mem_addr_set = true; + defaults_assumed = true; // Get entry address from loader, unless overridden if (!entry_addr_set) entry_addr = entry_address; if (!length_set) { length = load_address_end - load_address; length_set = true; - diag_printf("No memory address or length set.\n"); - if (!verify_action("Inferring base %p, length 0x%x", mem_addr, length)) - return; } else if (defaults_assumed && !img_size_set) { /* We got length from the FIS table, so the size of the actual loaded image becomes img_size */ img_size = load_address_end - load_address; img_size_set = true; - diag_printf("No memory address set.\n"); - if (!verify_action("Inferring base %p, length 0x%x, image size 0x%x, entry %p\n", - mem_addr, length, img_size, entry_addr)) - return; } } // Get the remaining fall-back values from the fis @@ -713,23 +707,24 @@ fis_create(int argc, char *argv[]) return; } } - // Find a slot in the directory for this entry - // First, see if an image by this name is already present - slot_found = false; - img = fis_lookup(name, NULL); + // First, see if the image by this name has agreable properties if (img) { if (flash_addr_set && (img->flash_base != flash_addr)) { - diag_printf("Image found, but FLASH address incorrect\n"); + diag_printf("Image found, but flash address (%p)\n" + " is incorrect (present image location %p)\n", + flash_addr, img->flash_base); + return; } if (img->size != length) { - diag_printf("Image found, but LENGTH is incorrect (0x%lx != 0x%lx)\n", img->size, length); + diag_printf("Image found, but length (0x%lx, necessitating image size 0x%lx)\n" + " is incorrect (present image size 0x%lx)\n", + img_size, length, img->size); return; } if (!verify_action("An image named '%s' exists", name)) { return; } else { - slot_found = true; if (defaults_assumed) { if (!verify_action("* CAUTION * about to program '%s'\n at %p..%p from %p", name, (void *)flash_addr, (void *)(flash_addr+img_size-1), @@ -738,13 +733,11 @@ fis_create(int argc, char *argv[]) } } } - } - // If not found, try and find an empty slot - if (!slot_found) { + } else { + // If not image by that name, try and find an empty slot img = (struct fis_image_desc *)fis_work_block; for (i = 0; i < fisdir_size/sizeof(*img); i++, img++) { if (img->name[0] == (unsigned char)0xFF) { - slot_found = true; break; } } @@ -794,7 +787,6 @@ fis_delete(int argc, char *argv[]) int num_reserved, i, stat; void *err_addr; struct fis_image_desc *img; - bool slot_found; if (!scan_opts(argc, argv, 2, 0, 0, (void **)&name, OPTION_ARG_TYPE_STR, "image name")) { @@ -806,7 +798,6 @@ fis_delete(int argc, char *argv[]) arm_fis_delete(name); return; #endif - slot_found = false; img = (struct fis_image_desc *)fis_work_block; num_reserved = 0; #ifdef CYGOPT_REDBOOT_FIS_RESERVED_BASE diff --git a/packages/redboot/current/src/fs/disk.c b/packages/redboot/current/src/fs/disk.c --- a/packages/redboot/current/src/fs/disk.c +++ b/packages/redboot/current/src/fs/disk.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/fs/e2fs.c b/packages/redboot/current/src/fs/e2fs.c --- a/packages/redboot/current/src/fs/e2fs.c +++ b/packages/redboot/current/src/fs/e2fs.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/fs/ide.c b/packages/redboot/current/src/fs/ide.c --- a/packages/redboot/current/src/fs/ide.c +++ b/packages/redboot/current/src/fs/ide.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/io.c b/packages/redboot/current/src/io.c --- a/packages/redboot/current/src/io.c +++ b/packages/redboot/current/src/io.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/load.c b/packages/redboot/current/src/load.c --- a/packages/redboot/current/src/load.c +++ b/packages/redboot/current/src/load.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -58,6 +58,9 @@ #ifdef CYGPKG_REDBOOT_DISK #include #endif +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD +#include +#endif // Buffers, data used by redboot_getc #define BUF_SIZE 256 @@ -78,7 +81,15 @@ static char usage[] = "[-r] [-v] " #ifdef CYGPKG_COMPRESS_ZLIB "[-d] " #endif - "[-h ] [-m {TFTP | xyzMODEM" + "[-h ] [-m {TFTP " +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD + "| HTTP" +#endif +#ifdef xyzModem_zmodem + "| {x|y|z}MODEM" +#else + "| {x|y}MODEM" +#endif #ifdef CYGPKG_REDBOOT_DISK " | disk" #endif @@ -508,8 +519,13 @@ redboot_getc_close(void) #define MODE_TFTP 0 #define MODE_XMODEM xyzModem_xmodem // 1 #define MODE_YMODEM xyzModem_ymodem // 2 +#ifdef xyzModem_zmodem #define MODE_ZMODEM xyzModem_zmodem // 3 +#endif #define MODE_DISK 4 +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD +#define MODE_HTTP 5 +#endif void do_load(int argc, char *argv[]) @@ -602,9 +618,11 @@ do_load(int argc, char *argv[]) case 'y': mode = MODE_YMODEM; break; +#ifdef xyzModem_zmodem case 'z': mode = MODE_ZMODEM; break; +#endif default: diag_printf("Invalid 'mode': %s\n", mode_str); return; @@ -616,6 +634,10 @@ do_load(int argc, char *argv[]) } else if (strcasecmp(mode_str, "disk") == 0) { mode = MODE_DISK; #endif +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD + } else if (strcasecmp(mode_str, "http") == 0) { + mode = MODE_HTTP; +#endif #ifdef CYGPKG_REDBOOT_NETWORKING } else if (strcasecmp(mode_str, "tftp") == 0) { mode = MODE_TFTP; @@ -638,8 +660,16 @@ do_load(int argc, char *argv[]) #endif #if CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS > 1 if (chan_set) { - if ((mode != MODE_XMODEM) && (mode != MODE_YMODEM) && (mode != MODE_ZMODEM)) { + if ((mode != MODE_XMODEM) && +#ifdef MODE_ZMODEM + (mode != MODE_ZMODEM) && +#endif + (mode != MODE_YMODEM)) { +#ifdef xyzModem_zmodem diag_printf("I/O channel can only be used with {xyz}Modem\n"); +#else + diag_printf("I/O channel can only be used with {xy}Modem\n"); +#endif return; } if (chan >= CYGNUM_HAL_VIRTUAL_VECTOR_NUM_CHANNELS) { @@ -683,6 +713,17 @@ do_load(int argc, char *argv[]) redboot_getc_init(disk_stream_read, verbose, decompress); } #endif +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD + else if (mode == MODE_HTTP) { + res = http_stream_open(filename, &host, &err); + if (res < 0) { + + diag_printf("Can't load '%s': %s\n", filename, http_error(err)); + return; + } + redboot_getc_init(http_stream_read, verbose, decompress); + } +#endif else { res = xyzModem_stream_open(filename, mode, chan, &err); if (res < 0) { @@ -762,6 +803,11 @@ do_load(int argc, char *argv[]) disk_stream_close(&err); break; #endif +#ifdef CYGSEM_REDBOOT_NET_HTTP_DOWNLOAD + case MODE_HTTP: + http_stream_close(&err); + break; +#endif #ifdef CYGPKG_REDBOOT_NETWORKING case MODE_TFTP: tftp_stream_close(&err); diff --git a/packages/redboot/current/src/main.c b/packages/redboot/current/src/main.c --- a/packages/redboot/current/src/main.c +++ b/packages/redboot/current/src/main.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -199,6 +199,9 @@ do_idle(bool is_idle) static void _mon_write_char(char c, void **param) { + if (c == '\n') { + mon_write_char('\r'); + } mon_write_char(c); } diff --git a/packages/redboot/current/src/misc_funs.c b/packages/redboot/current/src/misc_funs.c --- a/packages/redboot/current/src/misc_funs.c +++ b/packages/redboot/current/src/misc_funs.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/arp.c b/packages/redboot/current/src/net/arp.c --- a/packages/redboot/current/src/net/arp.c +++ b/packages/redboot/current/src/net/arp.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/bootp.c b/packages/redboot/current/src/net/bootp.c --- a/packages/redboot/current/src/net/bootp.c +++ b/packages/redboot/current/src/net/bootp.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/cksum.c b/packages/redboot/current/src/net/cksum.c --- a/packages/redboot/current/src/net/cksum.c +++ b/packages/redboot/current/src/net/cksum.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/dns.c b/packages/redboot/current/src/net/dns.c --- a/packages/redboot/current/src/net/dns.c +++ b/packages/redboot/current/src/net/dns.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //============================================================================= @@ -81,9 +81,6 @@ static int get_port = 7700; /* Some magic to make dns_impl.inl compile under RedBoot */ #define sprintf diag_sprintf -static cyg_addrword_t _thread_data; -static cyg_addrword_t cyg_thread_get_data(int i) { return _thread_data; } -static void cyg_thread_set_data(int i, cyg_addrword_t data) { _thread_data = data; } struct sockaddr_in server; @@ -102,7 +99,6 @@ static int _strings_alloc = 0; static short id = 0; /* ID of the last query */ static int s = -1; /* Socket to the DNS server */ static cyg_drv_mutex_t dns_mutex; /* Mutex to stop multiple queries as once */ -static cyg_ucount32 ptdindex; /* Index for the per thread data */ static char * domainname=NULL; /* Domain name used for queries */ @@ -165,6 +161,18 @@ alloc_hent(void) return hent; } +static __inline__ void +free_stored_hent(void) +{ + free_hent( &_hent ); +} + +static __inline__ void +store_hent(struct hostent *hent) +{ + hent=hent; // avoid warning +} + /* Send the query to the server and read the response back. Return -1 if it fails, otherwise put the response back in msg and return the length of the response. */ diff --git a/packages/redboot/current/src/net/enet.c b/packages/redboot/current/src/net/enet.c --- a/packages/redboot/current/src/net/enet.c +++ b/packages/redboot/current/src/net/enet.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/http_client.c b/packages/redboot/current/src/net/http_client.c new file mode 100644 --- /dev/null +++ b/packages/redboot/current/src/net/http_client.c @@ -0,0 +1,236 @@ +//========================================================================== +// +// net/http_client.c +// +// Stand-alone HTTP support for RedBoot +// +//========================================================================== +//####ECOSGPLCOPYRIGHTBEGIN#### +// ------------------------------------------- +// This file is part of eCos, the Embedded Configurable Operating System. +// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +// +// eCos is free software; you can redistribute it and/or modify it under +// the terms of the GNU General Public License as published by the Free +// Software Foundation; either version 2 or (at your option) any later version. +// +// eCos is distributed in the hope that it will be useful, but WITHOUT ANY +// WARRANTY; without even the implied warranty of MERCHANTABILITY or +// FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +// for more details. +// +// You should have received a copy of the GNU General Public License along +// with eCos; if not, write to the Free Software Foundation, Inc., +// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +// +// As a special exception, if other files instantiate templates or use macros +// or inline functions from this file, or you compile this file and link it +// with other works to produce a work based on this file, this file does not +// by itself cause the resulting work to be covered by the GNU General Public +// License. However the source code for this file must still be made available +// in accordance with section (3) of the GNU General Public License. +// +// This exception does not invalidate any other reasons why a work based on +// this file might be covered by the GNU General Public License. +// +// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +// at http://sources.redhat.com/ecos/ecos-license/ +// ------------------------------------------- +//####ECOSGPLCOPYRIGHTEND#### +//========================================================================== +//#####DESCRIPTIONBEGIN#### +// +// Author(s): gthomas +// Contributors: gthomas +// Date: 2002-05-22 +// Purpose: +// Description: +// +// This code is part of RedBoot (tm). +// +//####DESCRIPTIONEND#### +// +//========================================================================== + +// HTTP client support + +#include // have_net +#include +#include + +// So we remember which ports have been used +static int get_port = 7800; + +static struct _stream{ + bool open; + int avail, actual_len, pos, filelen; + char data[4096]; + char *bufp; + tcp_socket_t sock; +} http_stream; + +static __inline__ int +min(int a, int b) +{ + if (a < b) + return a; + else + return b; +} + +int +http_stream_open(char *filename, + struct sockaddr_in *server, + int *err) +{ + int res; + struct _stream *s = &http_stream; + + server->sin_port = 80; // HTTP port + if ((res = __tcp_open(&s->sock, server, get_port++, 5000, err)) < 0) { + *err = HTTP_OPEN; + return -1; + } + diag_sprintf(s->data, "GET %s HTTP 1.0\r\n\r\n", filename); + __tcp_write_block(&s->sock, s->data, strlen(s->data)); + s->avail = 0; + s->open = true; + s->pos = 0; + return 0; +} + +int +http_stream_close(int *err) +{ + struct _stream *s = &http_stream; + + if (s->open) { + __tcp_close(&s->sock); + s->open = false; + } + return 0; +} + +int +http_stream_read(char *buf, + int len, + int *err) +{ + struct _stream *s = &http_stream; + int total = 0; + int cnt, code; + + if (!s->open) { + return -1; // Shouldn't happen, but... + } + while (len) { + while (s->avail == 0) { + // Need to wait for some data to arrive + __tcp_poll(); + if (s->sock.state != _ESTABLISHED) { + if (s->sock.state == _CLOSE_WAIT) { + // This connection is breaking + if (s->sock.data_bytes == 0 && s->sock.rxcnt == 0) { + __tcp_close(&s->sock); + return total; + } + } + if (s->sock.state == _CLOSED) { + // The connection is gone + s->open = false; + + return -1; + } + *err = HTTP_IO; + return -1; + } + s->actual_len = __tcp_read(&s->sock, s->data, sizeof(s->data)); + if (s->actual_len > 0) { + s->bufp = s->data; + s->avail = s->actual_len; + if (s->pos == 0) { + // First data - need to scan HTTP response header + if (strncmp(s->bufp, "HTTP/", 5) == 0) { + // Should look like "HTTP/1.1 200 OK" + s->bufp += 5; + s->avail -= 5; + // Find first space + while ((s->avail > 0) && (*s->bufp != ' ')) { + s->bufp++; + s->avail--; + } + // Now the integer response + code = 0; + while ((s->avail > 0) && (*s->bufp == ' ')) { + s->bufp++; + s->avail--; + } + while ((s->avail > 0) && isdigit(*s->bufp)) { + code = (code * 10) + (*s->bufp - '0'); + s->bufp++; + s->avail--; + } + // Make sure it says OK + while ((s->avail > 0) && (*s->bufp == ' ')) { + s->bufp++; + s->avail--; + } + if (strncmp(s->bufp, "OK", 2)) { + *err = HTTP_BADHDR; + return -1; + } + // Find \r\n\r\n - end of HTTP preamble + while (s->avail > 4) { + // This could be done faster, but not simpler + if (strncmp(s->bufp, "\r\n\r\n", 4) == 0) { + s->bufp += 4; + s->avail -= 4; +#if 0 // DEBUG - show header + *(s->bufp-2) = '\0'; + diag_printf(s->data); +#endif + break; + } + s->avail--; + s->bufp++; + } + s->pos++; + } else { + // Unrecognized response + *err = HTTP_BADHDR; + return -1; + } + } + } else if (s->actual_len < 0) { + *err = HTTP_IO; + return -1; + } + } + cnt = min(len, s->avail); + memcpy(buf, s->bufp, cnt); + s->avail -= cnt; + s->bufp += cnt; + buf += cnt; + total += cnt; + len -= cnt; + } + return total; +} + +char * +http_error(int err) +{ + char *errmsg = "Unknown error"; + + switch (err) { + case HTTP_NOERR: + return ""; + case HTTP_BADHDR: + return "Unrecognized HTTP response"; + case HTTP_OPEN: + return "Can't connect to host"; + case HTTP_IO: + return "I/O error"; + } + return errmsg; +} diff --git a/packages/redboot/current/src/net/icmp.c b/packages/redboot/current/src/net/icmp.c --- a/packages/redboot/current/src/net/icmp.c +++ b/packages/redboot/current/src/net/icmp.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/inet_addr.c b/packages/redboot/current/src/net/inet_addr.c --- a/packages/redboot/current/src/net/inet_addr.c +++ b/packages/redboot/current/src/net/inet_addr.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/ip.c b/packages/redboot/current/src/net/ip.c --- a/packages/redboot/current/src/net/ip.c +++ b/packages/redboot/current/src/net/ip.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/net_io.c b/packages/redboot/current/src/net/net_io.c --- a/packages/redboot/current/src/net/net_io.c +++ b/packages/redboot/current/src/net/net_io.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -249,36 +249,24 @@ net_io_flush(void) int n; char *bp = out_buf; - while (out_buflen) { - if (tcp_sock.state == _CLOSE_WAIT) { - // This connection is tring to close - // This connection is breaking - if (tcp_sock.data_bytes == 0 && tcp_sock.rxcnt == 0) - __tcp_close(&tcp_sock); - } - if (tcp_sock.state == _CLOSED) { - // The connection is gone! - net_io_revert_console(); - break; - } #ifdef DEBUG_TCP - if (show_tcp) { - int old_console; - old_console = start_console(); - diag_printf("%s.%d\n", __FUNCTION__, __LINE__); - diag_dump_buf(out_buf, out_buflen); - end_console(old_console); - } + if (show_tcp) { + int old_console; + old_console = start_console(); + diag_printf("%s.%d\n", __FUNCTION__, __LINE__); + diag_dump_buf(out_buf, out_buflen); + end_console(old_console); + } #endif // SHOW_TCP - n = __tcp_write(&tcp_sock, bp, out_buflen); - if (n > 0) { - out_buflen -= n; - bp += n; - } - __tcp_poll(); + n = __tcp_write_block(&tcp_sock, bp, out_buflen); + if (n < 0) { + // The connection is gone! + net_io_revert_console(); + } else { + out_buflen -= n; + bp += n; } out_bufp = out_buf; out_buflen = 0; - __tcp_drain(&tcp_sock); // Check interrupt flag if (CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG()) { CYGACC_CALL_IF_CONSOLE_INTERRUPT_FLAG_SET(0); diff --git a/packages/redboot/current/src/net/ping.c b/packages/redboot/current/src/net/ping.c --- a/packages/redboot/current/src/net/ping.c +++ b/packages/redboot/current/src/net/ping.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/pktbuf.c b/packages/redboot/current/src/net/pktbuf.c --- a/packages/redboot/current/src/net/pktbuf.c +++ b/packages/redboot/current/src/net/pktbuf.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/tcp.c b/packages/redboot/current/src/net/tcp.c --- a/packages/redboot/current/src/net/tcp.c +++ b/packages/redboot/current/src/net/tcp.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -464,6 +464,15 @@ void case _SYN_SENT: /* active open not supported */ + if (tcp->flags != (TCP_FLAG_SYN | TCP_FLAG_ACK)) { + do_reset(s); + __pktbuf_free(pkt); + return; + } + s->state = _ESTABLISHED; + s->ack = ntohl(tcp->seqnum) + 1; + s->seq = ntohl(tcp->acknum); + send_ack(s); break; case _LISTEN: @@ -644,7 +653,7 @@ int s->next = tcp_list; -#if 1 +#if 0 /* limit to one open socket at a time */ if (s->next) { BSPLOG(bsp_log("tcp_listen: recursion error\n")); @@ -778,6 +787,9 @@ int } +/* + * Write up to 'len' bytes without blocking + */ int __tcp_write(tcp_socket_t *s, char *buf, int len) { @@ -803,3 +815,79 @@ int return len; } +/* + * Write 'len' bytes from 'buf', blocking until sent. + * If connection collapses, return -1 + */ +int +__tcp_write_block(tcp_socket_t *s, char *buf, int len) +{ + int total = 0; + int n; + + while (len) { + if (s->state == _CLOSE_WAIT) { + // This connection is tring to close + // This connection is breaking + if (s->data_bytes == 0 && s->rxcnt == 0) + __tcp_close(s); + } + if (s->state == _CLOSED) { + // The connection is gone! + return -1; + } + n = __tcp_write(s, buf, len); + if (n > 0) { + len -= n; + buf += n; + } + __tcp_poll(); + } + __tcp_drain(s); + return total; +} + +/* + * Establish a new [outgoing] connection, with a timeout. + */ +int +__tcp_open(tcp_socket_t *s, struct sockaddr_in *host, + word port, int timeout, int *err) +{ + // Fill in socket details + memset(s, 0, sizeof(tcp_socket_t)); + s->state = _SYN_SENT; + s->our_port = port; + s->his_port = host->sin_port; + s->pkt.buf = (word *)s->pktbuf; + s->pkt.bufsize = ETH_MAX_PKTLEN; + s->pkt.ip_hdr = (ip_header_t *)s->pkt.buf; + s->pkt.tcp_hdr = (tcp_header_t *)(s->pkt.ip_hdr + 1); + s->seq = (port << 16) | 0xDE77; + s->ack = 0; + if (__arp_lookup((ip_addr_t *)&host->sin_addr, &s->his_addr) < 0) { + diag_printf("%s: Can't find address of server\n", __FUNCTION__); + return -1; + } + s->next = tcp_list; + tcp_list = s; + + // Send off the SYN packet to open the connection + tcp_send(s, TCP_FLAG_SYN, 0); + // Wait for connection to establish + while (s->state != _ESTABLISHED) { + if (s->state == _CLOSED) { + diag_printf("TCP open - host closed connection\n"); + return -1; + } + if (--timeout <= 0) { + diag_printf("TCP open - connection timed out\n"); + return -1; + } + MS_TICKS_DELAY(); + __tcp_poll(); + } + return 0; +} + + diff --git a/packages/redboot/current/src/net/tftp_client.c b/packages/redboot/current/src/net/tftp_client.c --- a/packages/redboot/current/src/net/tftp_client.c +++ b/packages/redboot/current/src/net/tftp_client.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/timers.c b/packages/redboot/current/src/net/timers.c --- a/packages/redboot/current/src/net/timers.c +++ b/packages/redboot/current/src/net/timers.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/net/udp.c b/packages/redboot/current/src/net/udp.c --- a/packages/redboot/current/src/net/udp.c +++ b/packages/redboot/current/src/net/udp.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/parse.c b/packages/redboot/current/src/parse.c --- a/packages/redboot/current/src/parse.c +++ b/packages/redboot/current/src/parse.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/syscall.c b/packages/redboot/current/src/syscall.c --- a/packages/redboot/current/src/syscall.c +++ b/packages/redboot/current/src/syscall.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/ticks.c b/packages/redboot/current/src/ticks.c --- a/packages/redboot/current/src/ticks.c +++ b/packages/redboot/current/src/ticks.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/version.c b/packages/redboot/current/src/version.c --- a/packages/redboot/current/src/version.c +++ b/packages/redboot/current/src/version.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/redboot/current/src/xyzModem.c b/packages/redboot/current/src/xyzModem.c --- a/packages/redboot/current/src/xyzModem.c +++ b/packages/redboot/current/src/xyzModem.c @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -323,10 +323,12 @@ xyzModem_stream_open(char *filename, int int crc_retries = xyzModem_MAX_RETRIES_WITH_CRC; // ZM_DEBUG(zm_out = zm_out_start); +#ifdef xyzModem_zmodem if (mode == xyzModem_zmodem) { *err = xyzModem_noZmodem; return -1; } +#endif // Set up the I/O channel. Note: this allows for using a different port in the future console_chan = CYGACC_CALL_IF_SET_CONSOLE_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT); @@ -407,7 +409,11 @@ xyzModem_stream_read(char *buf, int size xyz.next_blk = (xyz.next_blk + 1) & 0xFF; // Data blocks can be padded with ^Z (EOF) characters // This code tries to detect and remove them +#ifdef xyzModem_zmodem if (xyz.mode != xyzModem_zmodem) { +#else + if (1) { +#endif if ((xyz.bufp[xyz.len-1] == EOF) && (xyz.bufp[xyz.len-2] == EOF) && (xyz.bufp[xyz.len-3] == EOF)) { @@ -517,8 +523,10 @@ void xyzModem_stream_terminate(int metho xyzModem_flush(); xyz.at_eof = true; break; +#ifdef xyzModem_zmodem case xyzModem_zmodem: // Might support it some day I suppose. +#endif break; } default: diff --git a/packages/redboot/current/src/xyzModem.h b/packages/redboot/current/src/xyzModem.h --- a/packages/redboot/current/src/xyzModem.h +++ b/packages/redboot/current/src/xyzModem.h @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== @@ -57,7 +57,8 @@ #define xyzModem_xmodem 1 #define xyzModem_ymodem 2 -#define xyzModem_zmodem 3 +// Don't define this until the protocol support is in place +//#define xyzModem_zmodem 3 #define xyzModem_access -1 #define xyzModem_noZmodem -2 diff --git a/packages/services/compress/zlib/current/ChangeLog b/packages/services/compress/zlib/current/ChangeLog --- a/packages/services/compress/zlib/current/ChangeLog +++ b/packages/services/compress/zlib/current/ChangeLog @@ -82,7 +82,7 @@ 2001-03-08 Jesper Skov -####ECOSGPLCOPYRIGHTBEGIN#### - ------------------------------------------- - This file is part of eCos, the Embedded Configurable Operating System. - Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. - - eCos is free software; you can redistribute it and/or modify it under - the terms of the GNU General Public License as published by the Free - Software Foundation; either version 2 or (at your option) any later version. - - eCos is distributed in the hope that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty of MERCHANTABILITY or - FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - for more details. - - You should have received a copy of the GNU General Public License along - with eCos; if not, write to the Free Software Foundation, Inc., - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. - - As a special exception, if other files instantiate templates or use macros - or inline functions from this file, or you compile this file and link it - with other works to produce a work based on this file, this file does not - by itself cause the resulting work to be covered by the GNU General Public - License. However the source code for this file must still be made available - in accordance with section (3) of the GNU General Public License. - - This exception does not invalidate any other reasons why a work based on - this file might be covered by the GNU General Public License. - - Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. - at http://sources.redhat.com/ecos/ecos-license - ------------------------------------------- -####ECOSGPLCOPYRIGHTEND#### +#####ECOSGPLCOPYRIGHTBEGIN#### +## ------------------------------------------- +## This file is part of eCos, the Embedded Configurable Operating System. +## Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc. +## +## eCos is free software; you can redistribute it and/or modify it under +## the terms of the GNU General Public License as published by the Free +## Software Foundation; either version 2 or (at your option) any later version. +## +## eCos is distributed in the hope that it will be useful, but WITHOUT ANY +## WARRANTY; without even the implied warranty of MERCHANTABILITY or +## FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License +## for more details. +## +## You should have received a copy of the GNU General Public License along +## with eCos; if not, write to the Free Software Foundation, Inc., +## 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +## +## As a special exception, if other files instantiate templates or use macros +## or inline functions from this file, or you compile this file and link it +## with other works to produce a work based on this file, this file does not +## by itself cause the resulting work to be covered by the GNU General Public +## License. However the source code for this file must still be made available +## in accordance with section (3) of the GNU General Public License. +## +## This exception does not invalidate any other reasons why a work based on +## this file might be covered by the GNU General Public License. +## +## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. +## at http://sources.redhat.com/ecos/ecos-license/ +## ------------------------------------------- +#####ECOSGPLCOPYRIGHTEND#### diff --git a/packages/services/power/common/current/include/power.h b/packages/services/power/common/current/include/power.h --- a/packages/services/power/common/current/include/power.h +++ b/packages/services/power/common/current/include/power.h @@ -36,7 +36,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/services/power/common/current/src/power.cxx b/packages/services/power/common/current/src/power.cxx --- a/packages/services/power/common/current/src/power.cxx +++ b/packages/services/power/common/current/src/power.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/services/power/common/current/src/power_data.cxx b/packages/services/power/common/current/src/power_data.cxx --- a/packages/services/power/common/current/src/power_data.cxx +++ b/packages/services/power/common/current/src/power_data.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/services/power/common/current/tests/powertest.cxx b/packages/services/power/common/current/tests/powertest.cxx --- a/packages/services/power/common/current/tests/powertest.cxx +++ b/packages/services/power/common/current/tests/powertest.cxx @@ -34,7 +34,7 @@ // this file might be covered by the GNU General Public License. // // Alternative licenses for eCos may be arranged by contacting Red Hat, Inc. -// at http://sources.redhat.com/ecos/ecos-license +// at http://sources.redhat.com/ecos/ecos-license/ // ------------------------------------------- //####ECOSGPLCOPYRIGHTEND#### //========================================================================== diff --git a/packages/templates/all/ChangeLog b/packages/templates/all/ChangeLog --- a/packages/templates/all/ChangeLog +++ b/packages/templates/all/ChangeLog @@ -124,7 +124,7 @@ 1999-12-09 Bart Veer