vxw_pt1.html

vxworks及tornado常见问题解答

<p>Q: I am trying to run the vxsys program provided with tornado 2.0 under
windows NT4.0 SP5.  I get an error "the system try to access directly to the disk,
this is not possible ....."

<p>A: I think VxSYS is DOS utility, and doesn't work under Windows
(at least NT4/5). You can't run it from DOS box, you need to actually boot
DOS.
<br>(From: Andray Kaganovsky, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.4-E"></a>

<p>Q: How can I create (encrypted) passwords?
<p>A: You can use vxencrypt that comes with Tornado to create passwords,
but it is pretty weak.

<br>I think it is sum( p[i] * i ^ i )) * 0x1e3a1d5 converted to ascii with
a munged hex character set (presumably to make you think there are
more than 2^32 encrypted passwords).
I think I could reverse that using pen and paper.

<p>You can also install your own encryption routine using
loginEncryptInstall().

<br>For a strong password [1], encrypt known plaintext using the password
as the key.  Unix traditionally uses DES - but that requires a
moderate amount of code.  I used 'TEA' - see
<A href="http://vader.brad.ac.uk">http://vader.brad.ac.uk</a>,
since it is unencumbered.

<p>[1] problematical since you have difficulty protecting the password
file as none of the vxWorks filesystems support user-ids.

<p>(From: David Laight)

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.5"><center>1.5 Installation</center></a></h3>

<a NAME="1.5-A"></a>
Q: When I try to install the GNU source CD I get an error meesage about the
file aux.h (permission denied). But that file does not exist. What is 
happening?
<p>A: There is a problem with the microsoft SW (as could be expected :-).
The name "AUX" is a reserved name. So any starting with "AUX." (with the dot)
cannot exist. This is also true for any filename starting witgh a device name,
for example you cannot open a filename with the name 'LPT1.TXT'.

<p>
<hr WIDTH="50%">

<a NAME="1.5-B"></a>
<p>Q: After I install Tornado or a patch to Tornado all my C-file types are
removed and Tornado is used to open the files. How can I change this back to my
normal editor?
<p>A: Tornado overwrites the entries in the registry. This can be repared using
the following .reg file.
<p><em>WARNING: be very carefull before using this file! Read it first and if
you don't understand it don't use it!</em>
<p><em>Another WARNING: This has been tested on Windows 95 and NT. When I have
the time I will also check this on other platforms. If you use this on another
platform (98, 2000) let me know if it works, or , if not, how to make it
work.</em> 
<p>Download the file first, then read it carefully, modify it so it executes
your editor and then execute it. How can you modify it?
<br>One way to do this is to execute the file, and then go to the Exporer and
open View-&gt;Options-&gt;File Types. Here you search for the file-type "C Source 
File" and "C Header File". Change the open command to the one you like. Now edit
the file c-files.reg and remove the part after line 20 (the first line starts 
with "[HKEY_CLASSES_ROOT\c_source_file]". The next time you execute this
registry entry all file types will be restored to the one you just selected.
<br>Another way is to find an entry in your File Types where your default
ewditor is used. Copy this line to the file c-files.reg in the lines where
a reference is made to vim (BTW: a very good editor, you can find more info
on <a href="http://www.vim.org">http://www.vim.org</a>).
<br>Now the file: <a href="c-files.reg">c-files.reg</a>

<p>
<hr WIDTH="50%">

<a NAME="1.5-C"></a>
<p>Q: When I double click on a file thatis opened in Tornado a new Tornado
session is started every time. I would like Tornado to be re-used, and all
files opened in the same Tornado session.
<p>A: Yes, this is possible. The following registry file will do that for you.
<p><em>WARNING: be very carefull before using this file! Read it first and if
you don't understand it don't use it!</em>
<p>If Tornado is not installed at c:\Tornado, edit the file before merging
it into your registry and adjust the path.
<br>Now the file: <a href="TornadoFileTypes.reg">TornadoFileTypes.reg</a>

<p>
<hr WIDTH="50%">

<a NAME="1.5-D"></a>
<p>Q: Is it possible to install multiple architectures into one tree?
<p>A: Yes, that is possible. There are however some points to take into account:
<ul>
<li>Install only the same version into the same tree. This means that Tornado
2.0.1 for ARM cannot be installed in the same tree as other versions. Also
do not mix Tornado 2.0 with 2.0.2.</li>
<li>The only incompatibility I found until now are with the MIPS architecture.
The following files gave problems after installing the idts134 BSP:
<ul>
<li>host\resource\tcl\wtxcore.tcl: in the last function the line
<code>set tool sfgnu</code> should be replaced by <code>set tool gnu</code>.
Between the 2 if-statement the line <code>set tool sfgnu</code> should be
aqdded again. Now only in case of MIPS the tool variable is changed. This
should be made more sofisticated, but if you are using only one MIPS-type
processor this should work.</li>
<li>host\resource\tcl\app-config\Browser: in line 138 there is a hard reference
to the directory obj...sfgnuvx. For other architectures this is directory is
called obj...gnuvx. This problem can be solved by replacing this line with
the follwoing lines:
<pre>    if { $cpuType($cpuId) == "RC32364" } {
        set name [wtxPath target lib obj$cpuType($cpuId)sfgnuvx]spyLib.o
    } else {
        set name [wtxPath target lib obj$cpuType($cpuId)gnuvx]spyLib.o
    }</pre>
and replace RC32364 with the name of your own processor-type.</li>
</ul>
</ul>

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.6"><center>1.6 Make</center></a></h3>

<a NAME="1.6-A"></a>
Q: Make can't find my include files in a separate directory
<p>A: Add the directories to the 'C/C++ Compiler' options, using -I&lt;dir&gt;.
Now include the following item in the properties of the build specification:
<blockquote>Macros: Name: VPATH
<br>Value: <code>$(filter-out -I.,$(filter -I%,$(CFLAGS)))</code>
</blockquote>
After a change of include dirs only the compiler options have to be updated.
The update of VPATH is automated by the rule above.
<br>After this change save the workspace to ensure that the changes are active. 
Now (re-)generate the dependencies and start the compiler.

<p>Bob Baker ([e-mail]) wrote about his experiences with the problem:
<p>We have been having lots of problems using tornado 2 when building an
application with the 'No rule to make target' appearing. Having tried all
the usual black magic cures. E.G. using ':' for VPATH separators instead of
spaces. Using 'space :' or ': space' or 'space : space', changing the order
of the macro's, forward slashes, back slashes, double slashes, pointing the
PC screen south at dawn etc the problem turned out to be incompatibility
between tornado 2 and win95/98. Simply copying the whole directory
structure containing the application and project files onto an NT box
solved the problem and produced a complete build. Copying onto another
win95 and win 98 box and the builds failed. The point of failure was where
the build was trying to access a file in a shared library on a network
drive. I have tried different combinations of seperator in the VPATH and
they all work on the NT box. 

<p>
<hr WIDTH="50%">
<a NAME="1.6-B"></a>
<p>Q: Why does make not regenerate my project after I changed a file in the BSP
directory (for example sysSerial.c) ?
<p>A: Within Tornado you can define directories that are not scanned for
include files. One of the default directories is the BSP directory 
(target\config). If you remove this from the exclude list the BSP files will
appear in the dependencies list.
<br>After you select to generate dependencies select the Advanced button. Now
you get a window with an item called "Read-only dependency path. Remove the
item .....\target\config from the list. Close the window, and regenerate all
the dependencies. The next time one of the BSP files is changed the files
will be generated correctly.
<br>(From: [e-mail])
<p>Another solution is not to remove this item, but to replace it with
.....\target\config\comps. Now you get all the files in the BSP directory,
but not the files in the comps directory, where a lot of "standard" files
are placed.

<p>
<hr WIDTH="50%">
<a NAME="1.6-C"></a>
<p>Q: How do I generate a linker list from within my project?
<p>A: The default linker commands as given in the properties of the build
specification are not used by make. To get make to use extra options for
the linker add the following item to the properties of the build spec:
<blockquote>Macros: Name: LD_PARTIAL_FLAGS_FOR_PARTIALIMAGE
<br>Value: -Wl,-Map,$(basename $(notdir $(PRJ_FILE))).link</blockquote>
Then modify the linker command line for LD_PARTIAL in target $(PROJECT_OUT)
in the file rules.vxApp:
<blockquote>$(LD_PARTIAL) $(LD_PARTIAL_FLAGS_FOR_PARTIALIMAGE) \
<br>$(PRJ_OBJS_FOR_LD_PARTIAL) $(PRJ_LIBS) -o partialImage.o</blockquote>
This generates a linker output file names &lt;Project&gt;.link in the output
directory. In this files the names are mapped to the original .o-files
and not to partialImage.o, what would happen if the file was generated
using the final link command.

<p>
<hr WIDTH="50%">
<a NAME="1.6-D"></a>
<p>Q: How do I generate a combined C and assembly file?
<p>A: Add the following rule to your Makefile:
<pre>%.out:          %.o
		@objdump$(TOOLENV) -S $&lt; &lt; $@</pre>
This will generate a file called &lt;file&gt;.out containing C and assembly
code. You need to have the -g flag for the compiler to get debug informtion
in the output file. This information is needed by objdump.
<p>But this is probably not enough. By default VxWorks puts a name in the
object file. This name consists of the absolute path of the project directory
with the complete path of the file name appended to it. (This can be seen with
the command "<code>objdump$(TOOLENV) --debugging &lt;object file&gt;</code>", in
the first few lines the filename is given.) This is caused by the fact that the
compiler is called with the complete path of the sourcefile. This can be changed
to ".." in the Makefile. But the Makefile is generated each time the
configuration is changed.
<br>To correct this the file prj_vxApp.tcl can be changed to write ".." to the
Makefile istead of the complete path. This is done in the function makeGen. The
original line in this function is:
<pre>
puts $fd "PRJ_DIR        = [file dir  [prjInfoGet $hProj fileName]]"
</pre>
This should be changed to:
<pre>
puts $fd "PRJ_DIR        = .."
</pre>
(With assistance from Bill Pringlemeir, [e-mail])
<p>
<hr WIDTH="50%">
<a NAME="1.6-E"></a>
<p>Q: How do I add extra .o files to my project?
<p>A: Add the files to the macto EXTRA_MODULES. The names can be sperated
with spaces. Be sure to have the object files in the same directory as
your other object files.
<br>It is also possible to place the files in the same directory as your
source files. In the macro you have to use ../&lt;object files name&gt;. The
advantage of this is that you can do a make clean or rebuild all without
loosing your own object files.

<p>
<hr WIDTH="50%">
<a NAME="1.6-F"></a>
<p>Q: I want to generate documentation using <code>make man</code> for
some extra files in my BSP, but only the documentation for sysLib.c gets
updated. I added my files to the line DOC_FILES in the BSP Makefile.
<p>A: In the make environment the DOC_FILES variable is not used. The
following changes should be made:
<ul>
<li>Add your files and the files as shown in the Makefile to the DOC_FILES
define in the Makefile. This line should look like:
<pre>DOC_FILES	= sysLib.c sysTffs.c tycoDrv.c myFile.c</pre></li>
<li>Change the file rules.x86-win32 to include the use of the DOC_FILES
variable. Change line 52 (containing the for statement) from:
<pre>
docs:
	@echo Processing
	@for %f in (sysLib sysTffs tyCoDrv) do @if exist %f.c @echo %f.c &amp; \
	    $(CPP) $(CASFLAGS) -C $(DOCFLAGS) %f.c &gt; %f.i &amp; \
</pre>
to:
<pre>
docs:
	@echo Processing
	@for %f in ($(basename $(DOC_FILES))) do @if exist %f.c @echo %f.c &amp; \
	    $(CPP) $(CASFLAGS) -C $(DOCFLAGS) %f.c &gt; %f.i &amp; \
</pre></li>
</ul>
As far as I can see this problem only occurs on a Windows platform and not on
a Unix platform.

<p>
<hr WIDTH="60%">

<p><h3><a NAME="1.7"><center>1.7 Project facility</center></a></h3>

<a NAME="1.7-A"></a>
Q: The project facility cannot be used with sub-projects within a project. How
do I manage these kind of projects?
<p>A: See the <a href="project.html">Project Facility</a> page for a 
description of this item.

<p>
<hr WIDTH="50%">
<a NAME="1.7-B"></a>
<p>Q: When I make changes to the file usrConfig.c the changes are not in my
application. How can I have these compiled into my application?
<p>A: Tornado 2.0 project does not use usrConfig.c
It uses "configulettes" instead , they can be found in <em>target/config/comps</em>
If you would like to use usrConfig.c , make the Makefile in
<em>target/config/yourBsp</em>
<br>(From: Roie Geron, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="1.7-C"></a>

<p>Q: How do I regenerate the project files outside of Tornado?
<p>A: Use the following command to regenerate these files from the directory
that contains the project file for a bootable project:
<pre>
wtxtcl &lt;Tornado base&gt;/host/src/hutils/configGen.tcl &lt;Project&gt;.wpj
</pre>
This is the command that is also used by Tornado. When the configuration
is changed this command can be seen as the first command that is executed
when a build is started.
<p>For downloadable projects there is no standard command. A modified version
of configGen can be used, called <a href="makeGen.tcl">makeGen.tcl</a>. Copy
this file to the ..../host/src/hutils directory. The Makefile can be generated
using the command:
<pre>
wtxtcl &lt;Tornado base&gt;/host/src/hutils/makeGen.tcl &lt;Project&gt;.wpj
</pre>
Be sure to use the complete pathname of the &lt;Project&gt;.wpj file

<p>
<hr WIDTH="50%">
<a NAME="1.7-D"></a>

<p>Q: When I generate dependencies some of the dependencies are missing. They
are outside the Tornado tree, but the directories are included using -I and
using the VPATH macro.
<p>A: We met the same problem before, you can change the include definition
from <code>#include "xxx\xxx\xxx.h"</code> to <code>#include "xxx/xxx/xxx.h"</code>,
then test it again. 
<br>(From: [e-mail]) 

<p>Something I found in this area is if this is occurs on a Windows
Host, make sure the directory name used in the -I statement is 
capatilized exactly as if this was a UNIX machine. If your directory
is MyDirectory and you put -ID:/MYDiRECtory, the project tool may
not be able to find the header files (at least on WinNT). I also 
was told to put my -I. as the last -I flag, but I am not too sure 
about that one. Things I do now when creating test applications or
building new projects, is that I put the -Ipath in my build properties
before I even start to add source file, because I have seen dependency
files that had no path associated with them, then of course you get the
no rules to make error. Here is some other info I got, but once again
you would have to take it with a grain of salt because it seems 
somewhat simplistic:
<ul>
<li>First change all <code>#include &lt;xxx.h&gt;</code>
to <code>#include "xxx.h"</code>

<br>If your includes are for headers that appear in multiple places, changing