vxw_pt2.html

vxworks及tornado常见问题解答

<br>(From: Eric Lucazeau ([e-mail]))

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

<p>Q: When I try to start an VxWorks image from T1 it runs, but when I try
to start the image compiled under T2 the system freezes.
<p>A: The problem was a file called "sysalib.s" in our vxWorks configuration
BSP.  It contains the first entrypoint for vxWorks.
<br>When we have compiled the image an warning was shown in the last line like
this
<br>"could not find _sysinit, set it to default 0x10000"
<br>After we added the file to the vxWorks build, it works fine.
<br>(From: "Achim Zimmer" ([e-mail]))

<p>
<hr WIDTH="50%">
<a NAME="2.3-F"></a>

<p>Q: Is it possible to boot from a compressed VxWorks image on a file system?
<p>A: Yes, that is possible. It can be done if you have enough RAM available.

<p>Take a look at the attached routine bootLoadModuleInflate() in 
<a href="bootLoadModInfl.c">bootLoadModInfl.c</a>,
intended to go in all/bootConfig.c.  It presents the same
interface as bootLoadModule(), except the file descriptor that
it takes is that of a deflated file.

<p>Code such as the following code can be used to automatically
call bootLoadModuleInflate() instead of bootLoadModule() when
the boot file name ends with a certain extension.  Then you can
boot either way.
<pre>
#define DEFLATED_EXT		".D"
#define DEFLATED_EXT_LEN	(sizeof (DEFLATED_EXT) - 1)
#define DEFLATED_FILE(fileName) \
	(strlen(fileName) &gt;= DEFLATED_EXT_LEN &amp;&amp; \
	 strcmp((fileName) + strlen(fileName) - DEFLATED_EXT_LEN, \
                  DEFLATED_EXT) == 0)

    /*
     * Support loading deflated or regular files.
     */

    if (DEFLATED_FILE(fileName)) {
	if (bootLoadModuleInflate(fd, pEntry) != OK)
	    goto readErr;
    } else {
	if (bootLoadModule (fd, pEntry) != OK)
	    goto readErr;
    }</pre>

Also, a Makefile rule like the following will help create
the required deflated file more easily.
<pre>
DEFLATE = ${WIND_BASE}/host/${WIND_HOST_TYPE}/bin/deflate
VX_BINARY = vxWorks.st

${VX_BINARY}.D: ${VX_BINARY}
        @echo "Deflating ${VX_BINARY} ==&gt; ${VX_BINARY}.D ...."
        ${DEFLATE} &lt; ${VX_BINARY} &gt; ${VX_BINARY}.D
</pre>
(From: Curt McDowell ([e-mail]))

<p>
<hr WIDTH="50%">
<a NAME="2.3-G"></a>

<p>Q: When I boot my target over an FTP connection the kernel is loaded in
a couple of seconds, but then the symbol table takes a much more time. Why
does the second phase take so much more time than the first part.
<p>A: The FTP client binds a port and lets vxWorks assign the port number.
VxWorks always assigns port numbers incrementing from 1024.  So first
the boot ROM uses port 1024 to load the image.  Then vxWorks resets
itself, causing it to use port 1024 again for the first file transfer
after boot.  Unfortunately, some servers don't let you re-use the
same port number for up to several minutes.  The port is kept
unusable in the TIMED_WAIT state.
<br>The problem may also occur if you reboot a system twice in a row
because the boot ROM tries to use port 1024 repeatedly.
<br>One fix is to call bind() a bunch of times in a loop during early
init.  This wastes port numbers.  The loop count may be chosen
pseudo-randomly, but then you may occasionally still have the
problem. It is better to store the loop count in NVRAM and
increment it by 16 or something every boot, modulo some number.
<br>Since doing this I have had no problems using any server.  Here's
my version of the routine sysBindFix().  It should be called
after usrNetInit() in usrConfig.c for the kernel, and also from a
convenient place in the boot ROM, such as before netLoad().
My implementation is appended below.

<pre>
#include "netinet/in.h"         /* for sysBindFix() */
#include "sockLib.h"            /* for sysBindFix() */

/*****************************************************************************
*
* Each time VxWorks is rebooted, it starts assigning system-assigned
* port numbers beginning at 1024.  Thus, if vxWorks is rebooted two or
* more times in succession, the same port number will be re-used.
*
* This behavior causes problems when vxWorks is being booted from a
* remote FTP server (particularly one running Solaris), because port
* 1024 goes into a TIME_WAIT state on the server and cannot be reused
* until it times out, typically in 2-4 minutes.
*
* This hack reduces the likelyhood of this happening by "wasting"
* a different number of system-assigned port numbers for each boot.
*/

void sysBindFix(void)
{
    UINT8               N;

    sysNvRamGet((char *) &amp;N, 1, NV_OFF_BINDFIX);
    N -= 16;
    sysNvRamSet((char *) &amp;N, 1, NV_OFF_BINDFIX);

    /* This is quite fast even when N=255 */

    while (N--) {
        int s;
        struct sockaddr_in saddr;
        saddr.sin_addr.s_addr = htonl(INADDR_ANY);
        saddr.sin_port = 0;
        saddr.sin_family = AF_INET;
        s = socket(AF_INET, SOCK_STREAM, 0);
        bind(s, (struct sockaddr *) &amp;saddr, sizeof(saddr));
        close(s);
    }
}</pre>
<br>(From: Curt McDowell, [e-mail])

<p><a NAME="2.3-G1"></a>
If the host is Solaris that you are booting from you can set TIMED_WAIT to
its minimum value, as root using 'ndd':
<ul>
<li>When using Solaris 2.6:
<pre>
ndd -set /dev/tcp tcp_close_wait_interval 1000
</pre></li>
<li>When using Solaris 2.7:
<pre>
ndd -set /dev/tcp tcp_time_wait_interval 1000
</pre></li>
</ul>
This will make the boot load and symbol table operate normal.
<p>I put a script in /etc/rc2.d to automate this on each reboot:
<pre>
#!/sbin/sh
#   for Solaris 2.7
# refer to ndd man page

case "$1" in
'start')
   if [ -f /usr/sbin/ndd  ]; then
      echo 'shortening tcp_close_wait_interval to 1000'
      /usr/sbin/ndd -set /dev/tcp/ tcp_close_wait_interval 1000
   fi
   ;;

'stop')
   ;;

*)
        echo "Usage: $0 { start | stop }"
        exit 1
        ;;
esac
exit 0
</pre>
(From: Jeff Szczepanski, [e-mail] and Bob Irwin
[e-mail])

<p>There is also a possible solution on the Vxworks side - make sure that
when the machine reboots, it does not reuse the same port numbers again.
This happens on fast reboots as well as switches between boot and memory
(vxWorks) images. A simple way to go about is to add code into useNetwork.c,
that creates a couple of additional sockets and binds them to dunamic ports.
<br>(From: Leonid Rosenboim, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="2.3-H"></a>

<p>Q: When I startup my target and want to download my VxWorks image using an
FTP session, and my ftp daemon is not yet available I have to manually restart
my target or use the bootprompt to start my system. How can I avoid this?
<p>A: You could try to increase the boot timeout, but that would also be the
case when your FTP deamon machine is available.
<br>Another option is to modify the boot process. Now, when the boot fails the
bootprompt apears. Modify it in such a way that the countdown starts
again. This means that after 10 seconds a new FTP action is started, and if
this fails 10 seconds later another is started.
<br>Be sure to have the bootloader react to a key however. The bootprompt
should apear when you press a key, so you can still modify the boot
parameters.

<p>
<hr WIDTH="50%">
<a NAME="2.3-I"></a>

<p>Q: Is it possible to make a "multi-boot"?
<p>A: Yes, VxWorks is quite capable of multi-booting. However, not without
some work on your part and then reburning the boot ROMs (or rebuilding the
boot image if you're using BOOTP).

<br>What you have to do is to modify the bootConfig.c
file in the area of the routine called the bootCmdLoop.

<br>You will need to define an alternate bootline and store
it somewhere.  You'll find an example in &lt;Your BSP&gt;/config.h.
It should look something like this:

<pre>
#define DEFAULT_BOOT_LINE \
"ei(0,0)host:/usr/vw/config/mv162/vxWorks h=90.0.0.3 e=90.0.0.50 u=target"

#define ALTERNATE_BOOT_LINE1 \
"scsi=0,0(0,0)intructor:/u/team7/vxWorks h=192.168.32.50 e=192.168.32.17
u=team7 tn=vx7 s=/sd0/startup.cmd o=ei"

#define ALTERNATE_BOOT_LINE2 \
"ei(0,0)intructor:/u/team7/vxWorks h=192.168.32.50 e=192.168.32.17 u=team7
tn=vx7 s=/u/team7/startup.cmd"
</pre>
Then, in bootConfig.c add the following global:

<pre>
char  secondChance = 2;
</pre>

Then, in bootConfig.c (bootCmdLoop) you would add something like this:

<pre>
    /* start autoboot, unless no-autoboot specified */

    bootStringToStruct (BOOT_LINE_ADRS, &amp;params);
    sysFlags = params.flags;

    if (!(sysStartType &amp; BOOT_NO_AUTOBOOT) &amp;&amp;
	!(sysFlags &amp; SYSFLG_NO_AUTOBOOT))
	{
	int timeout = TIMEOUT;

	if ((sysStartType &amp; BOOT_QUICK_AUTOBOOT) ||
	    (sysFlags &amp; SYSFLG_QUICK_AUTOBOOT))
	    {
	    timeout = 1;
	    }

	key = autoboot (timeout);	/* doesn't return if successful */
  } else {
	    int timeout = TIMEOUT;
      /* we only get here if the autoboot above fails */
  		switch (secondChance) {
				  case 2 :
                 strcpy (BOOT_LINE_ADRS, ALTERNATE_BOOT_LINE2);
                 secondChance--;
                 key = autoboot (timeout); /* doesn't return if successful */
                 break;
				  case 1 :
			  		     timeout = TIMEOUT;
                 strcpy (BOOT_LINE_ADRS, ALTERNATE_BOOT_LINE1);
                 secondChance--;
                 key = autoboot (timeout); /* doesn't return if successful */
                 break;
     }

  }
    /* If we're here, either we aren't auto-booting, or we got an error
     * auto-booting, or the auto-booting was stopped. */
</pre>

Make sure that the boot lines are configured properly and that
all of the devices that you are trying to boot from are known
to both the bootConfig.c (bootROM) and the usrNetwork.c and
usrLoadSym.c code if you're using the two step boot process
(load the O/S then the symbol table).  You will have to rebuild
the bootROM image for this to work.

<br>This code snippet actually supports booting from 3 different
devices as "failsoft" devices.  It trys the default NVRAM
bootline, then ALTERNATE_BOOT_LINE2 then ALTERNATE_BOOT_LINE1.
I've even had this default to dialing up via SLIP/PPP and booting
via modem -- the ultimate phone home ;-) -- if all else fails.

<br>(From: Mike Anderson, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="2.3-J"></a>

<p>Q: When I use a compressed VxWorks image a timeout resets my target before
my VxWorks becomes active. Is it possible te reset the watchdog during the
inflate?
<p>A: You can modify and rebuild the inflate function to include a function to
reset the watchdog. The sources can be found at:
<a href="http://www.info-zip.org/pub/infozip/zlib/">http://www.info-zip.org/pub/infozip/zlib/</a>
<br>(Bill Pringlemeir, [e-mail])

<p>
<hr WIDTH="50%">
<a NAME="2.3-K"></a>

<p>Q: How do I create a boot-disk?
<p>A: Creating Bootable Floppy from Boot-ROM:
<blockquote>
<ul>
<li>Open DOS window.</li>
<li>From DOS window execute
<code>tornado\host\x86-win32\bin\torvars</code>
(it will fix environment vars).</li>
<li>From the location of your boot-rom file (tornado\target\config\
BSP-dir\bootrom_uncmp) type
<code>mkboot a: bootrom_uncmp</code>. The mkboot utility will create a
bootable floppy
disk</li>
</ul>
</blockquote>


Creating Bootable Hard Disk from Boot-ROM:
<blockquote>
<ul>
<li>1st stage will be to prepare a Hard Disk that will be suitable for VxWorks
environment.</li>
<li>Prepare a Floppy Disk with DOS6.2, FDISK &amp; FORMAT files on it.</li>
<li>Turn off your PC, remove your HD and place VxWorks HD instead.</li>
<li>Boot your PC from DOS 6.2 Floppy Disk.</li>
<li>Run FDISK Create FAT16 2Gbyte partition and set it to be the active
partition.</li>
<li>Exit from FDISK, reboot from the Floppy Disk and format the HD by using the
FORMAT command from the Floppy Disk.</li>
<li>Turn Off your PC, reconnect your original HD, and add VxWorks HD as a
secondary HD (for example as disk D).</li>
<li>Turn ON your PC (Windows NT should be activated).</li>
<li>Open DOS window.</li>
<li>From DOS window execute <code>tornado\host\x86-win32\bin\torvars</code>
(it will fix environment vars).</li>
<li>From the location of your boot-rom file (tornado\target\config\
BSP-dir\bootrom_uncmp) copy bootrom_uncmp to file name bootrom.dat.</li>
<li>Type <code>vxsys d:</code>   (assuming VxWorks HD is mapped as disk D).
The vxsys.com installs a bootstrap loader that will be used to load
bootrom.sys file.</li>