Tornado核心工具Tornado软件工具包的核心工具是各个 Tornado软件工具包都具有的的开发工具主要包括以下几种：图形化的交叉调试器(Debugger)CrossWind/WDB 这是一个远程的源代码集成调试器，支持任务级和系统级调试，支持混合源代码和汇编代码显示，支持多目标机同时调试。这个高性能的调试器具有最新的提高生产率的图形化特征。加速器特征包括开发者可以成组地观察表达式的观察窗口；可以在调试器的图形用户界面中迅速改变变量、寄存器和局部变量的值；可以为不同组的元素设定根值数；通过信息规整和分类的方法有效地提供信息；还提供开发者熟悉的GNU/GDB调试器引擎，这种调试器引擎采用命令行方式、命令完成窗口和下拉式的历史记录窗口，因而具有很强的灵活性。开发者可以在目标运行系统上产生和调试任务，也可以将调试器和已经运行的任务连接在一起，这些任务可以是源自应用程序也可以是来自任务级调试环境。工程配置工具(Project Facility/Configuration)这是一个强有力的图形化工具，提供了可以对VxWorks操作系统及其组件进行自动地配置。自动的依赖性分析、代码容量计算和自动裁剪wizard大大缩短了开发周期。工程工具简化了 VxWorks应用程序的组织、配置和建立工作；同时，还使工程管理和VxWorks配置的许多方面实现自动化；这种集成的图形化工程管理环境还增强了开发小组的专业技术：单独的组件可以各自独立开发，然后由小组的其他成员共享和重用。由于建立了与现在流行的源代码控制系统的联系，例如：ClearCase、SCCS、RCS、PVCS、MS Visual SourceSafe等，所以允许小组中的各个成员可以平行工作而不互相干扰。Makefile自动生成维护软件工程维护自动的依赖性分析代码容量计算自动裁剪集成仿真器(Integrated Simulator)这种集成仿真器VxSim支持 CrossWind, WindView, Browser, 提供与真实目标机一致的调试和仿真运行环境。VxSim仿真器作为核心工具包含在各个软件包中，因而允许开发者可以在没有 BSP、操作系统配置、目标机硬件的情况下，使用 Tornado迅速开始开发工作。作为核心工具包含在各个软件包中的 VxSim都是限制版本，也就是说，它并不支持网络仿真；如果想获得全部功能的 VxSim，可以根据所买的软件包的条件从 WindPower可选工具进行选择。诊断分析工具(WindView for the Integrated Simulator) WindView是一个图形化的动态诊断和分析工具，主要是向开发者提供目标机硬件上实际运行的应用程序的许多的详细情况。这种系统级的诊断分析工具可以与VxSim一起使用。嵌入式系统开发者经常因为无法知道系统级的执行情况和软件的时间特性而感到失望，这种全功能版本的WindView提供了运行在集成仿真器上的 VxWorks应用程序的详细的动态

行为，图形化显示了任务、中断和系统对象相互作用的复杂关系。还可以选择用于监视目标硬件系统行为的WindView。C/C++编译环境(C/C++ Compilation Environment) Tornado提供交叉编译器、iostreams类库和一些列的工具来支持 C 语言和 C++语言。交叉编译器进行了许多优化，允许开发者能够迅速产生高效而简洁的代码。Diab C/C++ Compiler：唯一获得MOTOROLA 白金大奖的嵌入式编译器。GNU C/C++ Compiler： 应用最广泛的编译器。iostreams类库支持 C++中的格式化的和类型安全的 I/O，也可以扩展到用户自定义数据类型，这是 C++应用程序开发的工业标准。Tornado提供对 C++全面的支持，包括：异常事件处理、标准模板库(STL：Standard Template Library)、运行类型识别(RTTI：Run-Time Type Identification)、支持静态构造器和析构器的加载器、C++调试器，这些保证了工具与开发环境紧密地结合在一起。主机目标机连接配置器(Launcher)Tornado的主机目标机连接配置器 Launcher允许开发者轻松地设置和配置一定的开发环境，也提供对开发环境的管理和许多管理功能。目标机系统状态浏览器(Browser)Tornado的目标机系统浏览器 Browser是 Tornado shell的一个图形化组件，目标机系统状态浏览器 Browser的主窗口提供目标系统的全面状态总结，也允许开发者监视独立的目标系统对象：任务、信号灯、消息队列、内存分区、定时器、模块、变量、堆栈等。这些显示根据开发者的选择进行周期性或条件性更新。命令行执行工具(WindSh) Tornado的命令行执行工具WindSh是 Tornado所独有的功能强大的命令行解释器，可以直接解释执行 C 语句表达式、调用目标机上的 C 函数、访问系统符号表中登记的变量；还可以直接执行 TCL 语言。WindSh不仅可以解释几乎所有的 C 语言表达式，而且可以实现所有的调试功能。它主要有以下调试功能：下载软件模块；删除软件模块；创建并发起一个任务；删除任务；设置断点；删除断点；运行、单步、继续执行程序；查看内存、寄存器、变量；修改内存、寄存器、变量；查看任务列表、内存使用情况、CPU 利用率；查看特定的对象（任务、信号量、消息队列、内存分区、类）；复位目标机等等。多语言浏览器(WindNavigator)Tornado的多语言浏览器(WindNavigator)提供源程序代码浏览，图形化显示函数调用关系，快速地进行代码定位，这样大大地缩短了评价 C/C++源代码的时间。图形化核心配置工具(WindConfig)Tornado的图形化核心配置工具(WindConfig)使用图形向导方式智能化的自动配置VxWorks内核及其组件参数。增量加载器(Incremental Loader)Tornado的增量加载器(Incremental Loader)可以动态的加载新增模块并在目标机与内核实现动态链接运行，不必重新下载内核及未改动的模块，加快开发速度。

VxWorks / Tornado II FAQ(老站转)2. Changes/additions to be made to BSP's

2.1 Different BSP's

2.2 Processor specific issues

2.2.1 Power PC

2.2.2 I960

2.2.3 MIPS

2.2.4 ARM

2.3 Bootstrap

2.4 Adding component to your VxWorks configuration

2.5 VME problems

2.6 VxWorks environment

2.6.1 usrSerial.c

2.6.2 prj_vxworks.tcl

2.7 PCI problems

Index

--------------------------------------------------------------------------------

2. Changes/additions to be made to BSP'sQ: Where can I find documentation on how to build a BSP? A: More information on device drivers is available in the Tornado BSP developers kit(only available for Tornado 1.x). It covers several types at a high level, such as serial, network, scsi etc. The Vxworks Network programmers guide also does a little coverage of BSD style device drivers. The Network Protocol Toolkit Users Guide is also a pretty good source of information about network drivers. It is available online at the wrs website. A really good source if information is the souce code that comes with BSPs that you purchase from WRS. I have used their examples in conjunction with the available docs and this forum to create a couple of drivers for chips that were unsupported. (From: John Beauford, qjb005@email.mot.com)

--------------------------------------------------------------------------------

2.1 Different BSP'sIf you have made changes to a BSP please send them to me (Johan Borkhuis), so I can add them to this page. Motorola MBX860 Motorola MCP750 board

Motorola MV23xx/MVME27xx board Simulator (Sim-NT) PC-type systems

--------------------------------------------------------------------------------

2.2 Processor specific issues

--------------------------------------------------------------------------------

2.2.1 Power PCSee vxw_pt2_ppc.html.

--------------------------------------------------------------------------------

2.2.2 I960Q: Is there a compiler option or other method to compile under GNU for i960 byte aligned structures (PACKED)? I have try the -mno-code-align, -mno-strict-align, i960 compiler options. They did not help. A: Fred Roeber wrote the following in the newsgroup: I had similar problems with an i960 device driver. I spent some time going through the compiler code and manuals. This document is something I put together back then that I think might help. (From: Fred Roeber, froeber@bbn.com)

--------------------------------------------------------------------------------

2.2.3 MIPSQ: When I compile I get a lot of "... uses different e_flags ..." messages. What do these messages mean? A: Just received from Windriver support the following note regarding e_flags and MIPS. (From: Xjasartist@yahoo.com)

--------------------------------------------------------------------------------The message "uses different e_flags ... fields than previous modules ..." can occur for MIPS and PowerPC architectures. It should not cause any problems for MIPS processors most of

the time. If you look in the release notes for your MIPS BSP, you may find a comment something like: There are several types of warnings generated by compiler. These are harmless. During compilation of vxWorks image: uses different e_flags (0x0) fields than previous modules(0x10000001)For the case of MIPS, what's happening is that each ELF object module keeps track of which OMF affecting flags were used or specified anywhere in the original source file. Inside the linker, there is a function which copies the appropriate flags from the original object module to the one which is being created. For MIPS, the function is mips_elf_merge_private_bfd_data(). If two different files have different sets of flags, this might be a sign of a problem, so when the compiler finds this condition it prints the warning message above. Usually when this error message comes up with MIPS, it is from one of two different flags.

First is 0x1, which specifies that somewhere in the code a .noreorder directive was given. For MIPS, the name of this flag is EF_MIPS_NOREORDER. There should not be any problems related to this flag differing between the original object modules and the final module.

Second is 0x10000000, which is E_MIPS_ARCH_2. What this means is that some modules were compiled to use the ARCH 2 functionality. When you are using an ARCH 2 or ARCH 3 processor, this should also not be a problem.

The MIPS specific flags are:

/* Processor specific flags for the ELF header e_flags field. */

/* At least one .noreorder directive appears in the source. */#define EF_MIPS_NOREORDER 0x00000001

/* File contains position independent code. */#define EF_MIPS_PIC 0x00000002

/* Code in file uses the standard calling sequence for calling position independent code. */#define EF_MIPS_CPIC 0x00000004

/* Four bit MIPS architecture field. */#define EF_MIPS_ARCH 0xf0000000

/* -mips1 code. */#define E_MIPS_ARCH_1 0x00000000

/* -mips2 code. */#define E_MIPS_ARCH_2 0x10000000

/* -mips3 code. */#define E_MIPS_ARCH_3 0x20000000

In case you have the GNU source and want to find out more about this from there, this can be found in the file .../include/elf/mips.h below the top level GNU source directory. For PowerPC, the same error message may come up from the function ppc_elf_merge_private_bfd_data(). If this happens then the basic cause of the problem is the same as for MIPS, namely that the ELF output e_flags are different from the input flags. However, at this time our records do not contain indications about the differences in e_flags which actually occur, or even indications that this condition has ever occurred for PowerPC at all. Also, the PPC processor specific flags do not give any indication of similar conditions to the NOREORDER condition mentioned for MIPS above. If you find this error message when using PowerPC, please contact Wind River support.

--------------------------------------------------------------------------------

2.2.4 ARMQ: I am getting the following error: "unresolved symbol ___fixunsdfsi". But I never declare and use this symbol. A: ___fixunsdfsi converts double to unsigned int. For some (unkown) reason both ___fixunsdfsi and ___fixunssfsi (single to uint) are absent from the vxworks image. The following (untested) arm assembler probably does the job!

#define SGN_BIT 0x80000000 /* sign bit */#define MNT_SZ 20 /* mantissa bits in first word */

___fixunsdfsi:movs r12,r0,asr #MNT_SZ /* get sign and exponent */movmi r12,#0 /* convert -ve to zero *//* extract top 32 bits of mantissa */mov r0,r0,lsl #31 - MNT_SZmov r1,r1,lsr #MNT_SZ + 1orr r0,r0,r1orr r0,r0,#SGN_BIT /* add hidden bit */

sub r12,r12,#0x400rsbs r12,r12,#0x1e /* unbiassed and negated */bmi 10$mov r0,r0,lsr r12mov pc,lr

10$: /* overflow */mvn r0,#0mov pc,lr

I wrote the above as part of a full set of fp routines in order to get acceptable performance on a strongArm system. This routine isn't used, so hasn't been built. It is probably several orders of magnitude shorter than the one that gets generated from the gnu C FP library sources used for the ARM fp routines. (From: David Laight, dsl@tadpole.co.uk)

--------------------------------------------------------------------------------

Q: Information on implementing PCMCIA on StrongARM.

A: Implementing the pcmcia on the SA1110/SA1111 is painful to say the least. We have that hardware combination with 2 pcmcia sockets. PCIC.C/TCIC.c are the driver files, you need to write a similar file for the SA-1111. This is the hardware specific file. I found the pcic and tcic to be much more complicated than the SA-1111, so my driver file was simpler. Once the driver is implemented and working then you define an pcmcia adapter for the card, which references the functions in your driver. pcmciaLib.c, cisLib.c, pccardLib.c these are the higher level functions for the pcmcia, they had to be modified in various places to accomodate the hardware. I ended up making a local copy of all the files to work on. Here are some of the issues encountered. I don't know if you'll have the same problems or not. BTW, this is just a high level pass at the information, the devil is in the details.

VXWORKS implementation assumes a PC architecture. They assume both pcmcia slots used the same address space. I had to modify cislib.c (and problaby another file). So that it would reference the right address space for the socket. Interrupts. The SA1111 uses edge interrupts therefore it detects inserts (rising edge) or removals (falling edge or vice versa). I had to add a polling routing to reliably detect the card insert. SA1111 bug. We're using ATA cards. We found a problem where the Card does not handle 8 bit reads at odd addresses. I had to use a 16 bit read and mask off the appropriate bit. This causes a problem because the ATA spec. has data that is only valid with an 8-bit odd read.

This is just the tip of the iceberg but I hope it gets you started. I'm still struggling with getting it to work smoothly and reliable. I found the book "PCMCIA Developer's guide" to be useful. (From: Ann Davis, adavis@lightchip.com)

--------------------------------------------------------------------------------

2.3 BootstrapQ: How do I change the value of the counter during boot? A: Change the value of the define TIMEOUT in bootConfig.c to the right value, recompile the bootstrap and load this bootstrap in your target.

--------------------------------------------------------------------------------

Q: How can I change the boot parameters without a physcial serial to my target to change these at boot time?

A: Use the command "bootChange" from the target shell or host shell using Telnet or Rlogin. (From: Pete Kockritz (petekz@my-deja.com)

--------------------------------------------------------------------------------

Q: I get the message "Error in boot line:". Why is this message generated and how can I get rid of it?

A: The message is generated when bootStringToStruct() doesn't return a pointer to EOS. That happens when something in the bootline is not understood correctly and the processing terminates before the whole line has been read. What follows the message should be the bootline string with a ^ symbol under the part that was misunderstood... If you are getting garbage then that is probably the cause of the error ;-) (From: john_94501@my-deja.com)

--------------------------------------------------------------------------------

Q: When I try to boot my PC target using vxload I boot DOS without any config.sys or autoexec.bat. But still I get the error "Not enough memory to load". How can I get more memory available?

A: The line

shell=a:\vxworks\vxload.com a:\vxworks\bootromin "config.sys" saves free memory because "command.com" will not be loaded. (From: Eric Lucazeau (elucazeau@my-deja.com))

--------------------------------------------------------------------------------

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.

A: The problem was a file called "sysalib.s" in our vxWorks configuration BSP. It contains the first entrypoint for vxWorks. When we have compiled the image an warning was shown in the last line like this "could not find _sysinit, set it to default 0x10000" After we added the file to the vxWorks build, it works fine. (From: "Achim Zimmer" (hzimmer@dica.de))

--------------------------------------------------------------------------------

Q: Is it possible to boot from a compressed VxWorks image on a file system?

A: Yes, that is possible. It can be done if you have enough RAM available.

Take a look at the attached routine bootLoadModuleInflate() in bootLoadModInfl.c, 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.

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.

#define DEFLATED_EXT ".D"#define DEFLATED_EXT_LEN (sizeof (DEFLATED_EXT) - 1)#define DEFLATED_FILE(fileName) \(strlen(fileName) >= DEFLATED_EXT_LEN && \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;

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

${VX_BINARY}.D: ${VX_BINARY}@echo "Deflating ${VX_BINARY} ==> ${VX_BINARY}.D ...."${DEFLATE} < ${VX_BINARY} > ${VX_BINARY}.D

(From: Curt McDowell (csm@broadcom.com))

--------------------------------------------------------------------------------

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.

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. The problem may also occur if you reboot a system twice in a row because the boot ROM tries to use port 1024 repeatedly. 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. 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.

#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 *) &N, 1, NV_OFF_BINDFIX);N -= 16;sysNvRamSet((char *) &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 *) &saddr, sizeof(saddr));close(s);}}

(From: Curt McDowell, csm@broadcom.com) If the host is Solaris that you are booting from you can set TIMED_WAIT to its minimum value, as root using 'ndd':

When using Solaris 2.6: ndd -set /dev/tcp tcp_close_wait_interval 1000

When using Solaris 2.7: ndd -set /dev/tcp tcp_time_wait_interval 1000

This will make the boot load and symbol table operate normal. I put a script in /etc/rc2.d to automate this on each reboot:

#!/sbin/sh# for Solaris 2.7# refer to ndd man page

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

'stop');;

*)echo "Usage: $0 { start | stop }"exit 1;;esacexit 0

(From: Jeff Szczepanski, jszczep1@rochester.rr.com and Bob Irwin bobi@systemsinterface.com) 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. (From: Leonid Rosenboim, leonid@bitband.com)

--------------------------------------------------------------------------------

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?

A: You could try to increase the boot timeout, but that would also be the case when your FTP deamon machine is available. 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.

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.

--------------------------------------------------------------------------------

Q: Is it possible to make a "multi-boot"?

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). What you have to do is to modify the bootConfig.c file in the area of the routine called the bootCmdLoop. You will need to define an alternate bootline and store it somewhere. You'll find an example in /config.h. It should look something like this:

#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.17u=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=team7tn=vx7 s=/u/team7/startup.cmd"

Then, in bootConfig.c add the following global: char secondChance = 2;

Then, in bootConfig.c (bootCmdLoop) you would add something like this: /* start autoboot, unless no-autoboot specified */

bootStringToStruct (BOOT_LINE_ADRS, ¶ms);sysFlags = params.flags;

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

if ((sysStartType & BOOT_QUICK_AUTOBOOT) ||(sysFlags & 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. */

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. 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. (From: Mike Anderson, mike@chipware.com)

--------------------------------------------------------------------------------

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?

A: You can modify and rebuild the inflate function to include a function to reset the watchdog. The sources can be found at: http://www.info-zip.org/pub/infozip/zlib/ (Bill Pringlemeir, bpringlemeir@yahoo.com)

--------------------------------------------------------------------------------

Q: How do I create a boot-disk?

A: Creating Bootable Floppy from Boot-ROM:

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

--------------------------------------------------------------------------------

Q: When booting using the wu_ftpd shipped with RedHat 6.2 the booting hangs during the download.

A: The system does not hang, if you wait until the connection times-out you will see that the system boots. Some more research turned up a plausible explanation of the problem on the wu ftp web site (the Red Hat Linux ftp server) and the fix was pretty simple.

Basically, the ftp server has been made more RFC "insistent" and this caused the VxWorks boot code to break (it also broke Lynx, Midnight Commander and various other programs so WRS were not alone!). The patch is to close the data connection immediately after the read returns EOF (ie the other end has signalled a close). This is consistent with the FTP RFC 959. The patch should be safe (the data connection is no longer used), and it works for me with the ftp daemon (wu ftpd) on Linux Red Hat 6.0, 6.2, as well as the ftp supplied fom WRS for Windows - wftpd version 2.03. So, in bootConfig.c, in the 2 places where the connection is terminated (normal case and error case). Move the close(fd) up after the read. That is:

/* Empty the Data Socket before close. PC FTP server hangs otherwise */

while ((read (fd, command, sizeof (command))) > 0);/* Close data connection nowclose (fd);

See http://www.wu-ftpd.org/broken-clients.html for more info. (From: paulvroberts@my-deja.com)

--------------------------------------------------------------------------------

Q: What does the "hostname" field in the boot-parameters mean?

A: The host name field in the boot line refers to the card/machine that has the host inet address. This hostname will appear on your 'devs' list so that you can access the host machine through the target. There's another field called target name that used for the name of the card/machine that the image is running on. Look in Section 13 of the VxWorks Networks Programmer's Guide for an explanation of all the fields. (From: Christian Gan, cgan@iders.ca)

--------------------------------------------------------------------------------

Q: I boot from my Disk On Chip, but now I get unresolved symbols when I try to access a symbol.

A: First you have to generate the symbol table. When you include this with your image you have to copy this (much larger) VxWorks file to your target. When you create a seperate symbol file you must put the vxworks.sym (the symbol table ) in the same site of the

vxworks image. vxworks.sym is created when you build the vxworks image. (From: ilavin@alumnos.uva.es)

--------------------------------------------------------------------------------

2.4 Adding component to your VxWorks configurationQ: How do I add a new component to my configuration? A: The component structure is defined in the .cdf files, so study these first. Before you start to add your component you should answer 3 questions:

During which startup routine should the initialization take place? (see prjConfig.c for startup routines) Where in the component structure should your component be defined? What items should be visible (and editable) to the users during configuration? Also define a constant that should be used to enable the component. The following actions should be taken after you answered these questions: Create a CDF file for your component. This file can include the following item (some of these are required): NAME: The name of your component, as it should appear in the component list. SYNOPSIS: The description of your component. MODULES: The object modules to load. INIT_RTN: The routine that should be called to initialize your component HDR_FILES: The header file. CONFIGLETTES: The source files that define your component. This source file will be included in the prjConfig.c. CFG_PARAMS: The configuration parameters. These will appear as defines in the file prjParams.h. For each of the parameters an extra parameter definition can be given. In this item the name, the type and the default value can be defined Be sure to place the header and source file in a place that will be searched. The CDF file should have the name 00.cdf. If it is a architecture independent component place it in target\config\comps\vxWorks, otherwise place it in target\comps\vxWorks\arch\. For a good example see the item FOLDER_CLOCK, and follow all the items. Find the right InitGroup item in the file 00VxWorks.cdf. This file is located in target/config/comps/vxWorks. Now add the line INCLUDE_ at the right place in the list of include statements. Don't forget to add a backslash to this line (or the one above if the component is added at the end). Now find in the file 00VxWorks.cdf or 00BSP.cdf (in the same directory) the right folder to put your component. Add don't forget the backslash. For an example look here: Add memDrv as a component NOTE: there is probably a better way to define new components using extra tools. I don't have these tools so I had to find another way to include my new components.

--------------------------------------------------------------------------------

2.5 VME problemsQ: How do I implement VME Bus Auto ID on the MVME-2604 Power PC. The BSP states it supports the VME-64 standard. A: Andrew Fraser wrote some notes about this. This can be found here: vmeAutoId.html

--------------------------------------------------------------------------------

Q: Is it possible to configure vxWorks so that it makes use of external VME memory as part of the local memory?

A: Your VME-memory should be accessible via standard VME-setup, if not change your sysPhysMemDesc[] in sysLib.c and / or your VME-settings parameters. On boot you may add your memory by a call to memAddToPool(). I would recommend to insert this call in function sysHwInit2() in sysLib.c. (From: "Michael Lawnick, Lawnick@softec.de)

--------------------------------------------------------------------------------

Q: Another card on the VME bus is generating a bus error. How can I avoid that my SW will be stoppen by this error?

A: I was able to make my own version of VxMemProbe that's a lot faster and recovers from bus errors. Here's what worked for me:

jmp_buf myEnv;

void mySigHandler(int sigNum){longjmp(myEnv, ERROR);}

// Call this once before calling the Probe() routine below.void myByteProbeInit(){struct sigaction newSig, oldSig;

newSig.sa_handler = mySigHandler;newSig.sa_mask = 0;newSig.sa_flags = 0;

sigaction(SIGBUS, &newSig, &oldSig);sigaction(SIGSEGV, &newSig, &oldSig);}

STATUSmyByteProbe(char *addr, int mode, char *data){if(setjmp(myEnv) == 0){if(mode == READ) *data = *addr;else *addr = *data;}elsereturn (ERROR);}

(From: Mark A. Naivar, mnaivar@alvie-mail.lanl.gov)

--------------------------------------------------------------------------------

2.6 VxWorks environment

--------------------------------------------------------------------------------

2.6.1 usrSerial.cQ: When I define more than 10 serial lines I only get 10 serial lines. A: There is an error in usrSerial.c, in the function itos. In this function there is the following line:

val = val - (val %= 10);

This should be changed into: val = (val - (val % 10))/10;

--------------------------------------------------------------------------------

2.6.2 prj_vxworks.tclQ: When I create a new bootable project all items in the VxWorks tab are marked as "not installed". How can I get these back?

A: This is caused by the fact that an extra library has been defined in your BSP Makefile (LIB_EXTRA = ...). The project is generated only with the first library to look for the objects needed for the BSP. It is possible to change this. The file where the project is generated is prj_vxWorks.tcl. This file can be found in host/resource/tcl/app-config-Project. In this file the following changes must be made:

*** prj_vxWorks.tcl-old Mon Jan 24 12:08:26 2000--- prj_vxWorks.tcl Mon Aug 7 14:33:51 2000*** 895,905 ****set wcc [file tail $bspDir]wccCreate $hProj $wccwccCdfPathSet $hProj $cdfPathforeach lib [bspMakeGet LIBS] {! if {[string match *lib[bspMakeGet CPU]*.a $lib]} {! set mxrLibs [file tail $lib]! break! }}if {![info exists mxrLibs]} {set mxrLibs lib[bspMakeGet CPU][bspMakeGet TOOL]vx.a--- 895,905 ----set wcc [file tail $bspDir]wccCreate $hProj $wccwccCdfPathSet $hProj $cdfPath+ set mxrLibs ""foreach lib [bspMakeGet LIBS] {! if {[string match *lib[bspMakeGet CPU]*.a $lib]} {! lappend mxrLibs [file tail $lib]! }}if {![info exists mxrLibs]} {set mxrLibs lib[bspMakeGet CPU][bspMakeGet TOOL]vx.a

--------------------------------------------------------------------------------

2.7 PCI problemsQ: Information about PCI configuration. A: From James Marshall (james_marshall@agilent.com): I've just broken through into a clearing in the jungle of PCI Configuration & VxWorks on various PC platforms including CompactPCI. Some things I found useful on the journey:

There's a brief WindRiver Technical Note, WTN-49, that talks about some of these issues - it's on Windsurf. In particular it covers VME window mapping, if only briefly. PCI System Architecture by Tom Shanley & Don Anderson, part of the MindShare series. Linux source for PCI configuration. I used the source browser at lxr.linux.no to look at (for example) drivers/pci/pci.c http://lxr.linux.no/source/drivers/pci/pci.c?v=2.4.0-test7. It lets you click on identifiers to uncover where they are defined and used. For interpreting PCI Config registers, the PCICFG program might help:http://www.cs.cmu.edu/~ralf/pub-files/rbpci119.zip. The VxWorks PCI show routines aren't included from Project - you need to edit config.h in your (locally-copied) BSP and define INCLUDE_SHOW_ROUTINES. Unfortunately, this is very coarse-grained and pulls in several other unrelated show routines. I guess you could always write a .cdf file to add it to Project. In your driver you would use PCI routines from sysLib [pcPentium]: pciFindDevice() to get the config address (bus,device,function) for each instance of your device, then read the appropriate BAR(s) to get their address(es). I guess your master/slave window stuff mentioned in WTN-49 comes in at that point.

Note that the PCI Auto Config Library (src/drv/pci/pciAutoConfigLib.c) mentioned in WTN-49 isn't supported on x86 targets because the PCI BIOS (a callable part of the BIOS) is expected to do all PCI configuration before the OS boots. This is why the default setting for PCI_CFG_TYPE on x86 targets is PCI_CFG_NONE.

--------------------------------------------------------------------------------The abocve is no longer true for all BSP's. For example, the CPV5350 BSP does support PCI_AUTOCONF. If you enable it then the BSP will re-configure the bus, overriding what the BIOS did. (From: Chris Brand)

Tornado采用支持主机/目标机开发模式。本节以 x86系列目标机为例介绍调试环境的建立。7.1.1 配置文件 config.h目标机运行的程序包括两部分：引导文件 bootrom.sys和操作系统影像文件VxWorks。引导文件 bootrom.sys的主要作用类似于BIOS，一般它存放在一张软盘或目标机硬盘或目标机 FLASH 盘上，由Vxld 或其他程序加载到内存，用于初始化目标机上的包括引导硬件在内的硬件，建立VxWorks运行的环境，从引导设备上加载 VxWorks操作系统影像，并将CPU的控制权移交给操作系统。VxWorks是操作系统的影像文件。它是应用程序和目标代理程序（调试环境的目标机部分）运行的软件平台，一般存放在 bootrom.sys所在软盘或目标机硬盘或目标机 FLASH 盘，或主机硬盘上，由 bootrom.sys的引导程序加载到目标机内存。bootrom.sys和VxWorks这两个可以利用 Tornado提供的工具，按照配置文件 config.h有关设置自动生成。特定BSP的配置文件 config.h在该 BSP目录下。如 pc486的配置文件是 Tornado

\target\config\pc486\config.h。配置文件 config.h主要定义了引导行，目标机操作系统包含的主要成分，如软驱、IDE硬盘、SCSI设备、网络等设备驱动，文件系统（DOSFS，TFFS，CDROMFS等），调试方式，内存地址等及有关参数。引导行（boot line）定义了引导设备、引导路径、操作系统文件名、主机/目标机 IP地址、子网掩码、FTP用户名和口令等参数。对于X86平台目标机，引导设备可以是软盘（fd），硬盘（ata 或 ide），FLASH 盘（tffs），网卡（elt、ene等）等。一般采用通过以太网或通过RS232 或 RS422标准串口连结进行调试。在X86平台上，首先确定调试手段，是通过网络还是串口调试？然后按下面的步骤建立调试环境：1 修改配置文件2 生成 bootrom_uncmp引导文件和VxWorks 影像文件3 制作启动软盘4 配置主机环境5 用启动软盘启动目标机6 从主机搭接（attach）到目标机下面详细介绍。7.1.2 网络连接使用以太网连结调试方式，通过网口使用 FTP 协议从主机下载 VxWorks 映像。在X86平台上，一般使用启动软盘来启动目标机。首先要确定目标机使用的网卡型号。VxWorks5.4支持的网卡可以参考 config.h 文件。需要包含相应的 INCLUDE_XXX。常用的如下表：表 7.1 VxWorks5.4支持的几种常用网卡INCLUDE_XXX 网络接口卡 备注INCLUDE_ENE Eagle/Novell NE2000接口卡 包括兼容卡，不支持即插即用方式INCLUDE_ELT 3COM EtherLink III接口卡 包括兼容卡，不支持即插即用方式INCLUDE_EL_3C90X_END 3com fast etherLink XL PCI网卡 3Com3c905系列INCLUDE_FEI Intel Ether Express PRO100B PCI接口卡 INCLUDE_LN_97X_END AMD 79C972网卡 1 修改 config.h修改 config.h最重要的一步是修改引导行。引导文件 bootrom.sys根据引导行来确定引导设备、引导路径、操作系统文件，并且引导行存放在固定的位置。操作系统访问引导行来确定网络的配置，系统 reboot时也将访问引导行。bootrom.sys和VxWorks将它转换为一个特定的引导参数结构 BOOT_PARAMS 。在 config.h中，引导行定义为有特定格式的字符串。BOOT_PARAMS定义在 h\bootlib.h中。解释如下：typedef struct /* 引导参数结构 BOOT_PARAMS */{char bootDev [BOOT_DEV_LEN]; /* 引导设备代码 */char hostName [BOOT_HOST_LEN]; /* 主机名 */char targetName [BOOT_HOST_LEN]; /* 目标机名 */

char ead [BOOT_TARGET_ADDR_LEN]; /* 目标机以太网地址*/char bad [BOOT_TARGET_ADDR_LEN]; /* 底板以太网地址 */char had [BOOT_ADDR_LEN]; /* 主机以太网地址 */char gad [BOOT_ADDR_LEN]; /* 以太网网关 */char bootFile [BOOT_FILE_LEN]; /* 引导文件名 */char startupScript [BOOT_FILE_LEN]; /* 启动脚本文件名*/char usr [BOOT_USR_LEN]; /* 用户名 */char passwd [BOOT_PASSWORD_LEN]; /* 口令 */char other [BOOT_OTHER_LEN]; /* 留给应用程序使用 */int procNum; /* 处理器号*/int flags; /* 配置标示*/int unitNum; /* 网络设备编号 */} BOOT_PARAMS;

以 ISA 3COM3c509b网卡为例，网卡需要设置为非即插即用方式，中断号为 5，IO 端口为 0x300。主机 IP地址为 222.1.5.169，目标机 IP地址为 222.1.5.36。主机名为VxHost，有一 FTP用户VxMe，口令为 isMe。对应的引导行应为：“elt(0,0)VxHost:\tornado\target\config\pc486\vxWorks h=222.1.5.169 e=222.1.5.36 u=VxMe pw=isMe tn=VxTarget”解释如下：ene /* 启动设备名，为 ISA3COM3c509网卡，ne2000网卡应为 ene */ VxHost /* 主机标名，可以任意填写，不影响启动过程 */ \tornado\target\config\pc486\vxWorks /* 需要从主机加载的路径及映像文件名 */

h=222.1.5.169 /* 主机的 IP地址 */ e=222.1.5.36 /* 目标机的 IP地址 */ u= VxMe /* 用户名，主机的 Ftp 服务器必须有相应的同名用户 */ pw= isMe /* 口令，必须与主机的 Ftp 服务器相应的同名用户的口令相同*/ tn= VxTarget /*目标名，可以任意设置，不影响启动过程*/

将下面的一行#undef INCLUDE_ELT /* uninclude 3COM EtherLink III interface */该为：#define INCLUDE_ELT /* include 3COM EtherLink III interface */

还要修改下面的定义#define IO_ADRS_ELT 0x240#define INT_LVL_ELT 0x0b为：#define IO_ADRS_ELT 0x300 /* 网卡 I/O地址 */#define INT_LVL_ELT 0x05 /* 网卡中断号 */

config.h 修改完毕，下一步是生成目标文件 bootrom.sys和V xWorks。

2 生成目标文件 bootrom.sys和VxWorks先生成 bootrom_uncmp。在 Tornado集成环境中执行菜单命令Build-〉Build Boot ROM…，在弹出的对话框中，左边框中选择 BSP，选中 pc486，右边框中选择要生成的影像文件，选择 bootrom_uncmp，然后点击 OK 确认。Tornado将生成 bootrom_uncmp。再生成VxWorks。在 Tornado集成环境中执行菜单命令Build-〉Standard BSP Builds…。（如果没有该项，请执行菜单命令 Tools-〉Options…，在弹出的对话框中，选中 Project 页，选择 Show Tornado 1.0.1 menu items,点击 OK 确认）。与生成 bootrom_uncmp类似，在弹出的对话框中，BSP 选择 pc486，影像文件，选择 VxWorks。然后点击 OK 确认。Tornado将生成VxWorks。注意，必要时先进行 clean操作3 制作启动软盘 拷贝 Tornado\target\config\pc486\bootrom_uncmp 至 Tornado\host\bin下；准备一张已格式化的空盘插入软驱；在目录 Tornado\host\bin下执行命令mkboot a: bootrom_uncmp注意，有时，我们需要改变配置参数，重新生成引导文件，如果软盘已经是可引导的，那么只需更换软盘上的引导文件即可，方法是：del a:. (需要键入’y’确认删除)vxcopy bootrom_uncmp a:bootrom.sys

4 配置主机环境主机操作系统Win95 安装目录下有一文件 hosts.sam，向其中加入： 主机 IP 主机名 目标机 IP 目标机名启动 Tornado组件 FTP Server，在WFTPD窗口中选择菜单 Security中的User/right...,在其弹出窗口中选择 New User...，根据提示信息输入登录用户名和口令，并且要指定下载文件VxWorks所在根目录。可能还需要选取主菜单 Logging中 Log options、Enable Logging、Gets 、Logins 、Commands 、Warnings 选项。5 用启动软盘启动目标机将系统引导软盘插入目标机软驱，加电启动，目标机即通过 FTP方式从主机下载 VxWorkst系统。在控制台上可以看到启动信息。如果需要修改，在等待用户配置时，按 c 键，进行相应修改。（注意：配置信息要与主机配置、Ftp 服务器配置一致），修改结束后，按@键重新启动目标机。6 从主机搭接（attach）到目标机在 Tornado集成环境中点取 Tools 菜单，选取 Target Server，选择 config...；在Configure Target Servers窗口中先给目标服务器命名； 在配置目标服务器窗口中的“Target Servers Property”窗口中，选择 Back End；在“Available Back”窗口中选择 wdbrpc，在“Target IP/Address”窗口中输入目标机 IP（本

例为 222.1.5.36）；在配置目标服务器窗口中的“Target Servers Property”窗口中，选择 Core File and Symbols, 选择 File为BSP目标文件所在目录（本例为 PC486目录）的VxWorks，并选取为AllSymbols；在配置目标服务器窗口中的" Target Servers Property"窗口中的其它各项可根据需要选择;点击 Launch 按钮，连接主机和目标机，全部出现 successed后即可进入应用程序调试；点击图形按钮中下拉框，选择和主机相连的目标机。即可建立主机目标机连接。 这时 Shell、Debugger等按钮可用。7.1.3 串口连接串口连接一般从启动软盘下载 VxWorks 映像。其步骤如下：1 修改通用配置文件在 config.h 文件中加入以下宏定义： #define INCLUDE_WDB #define INCLUDE_WDB_TTY_TEST #undef WDB_COMM_TYPE #define WDB_COMM_TYPE WDB_COMM_SERIAL /*定义通信方式为串口联结*/ #define WDB_TTY_CHANNEL 1 /*通道号，目标机串口 2*/ #define WDB_TTY_BAUD 9600 /*串口速率，VxWorks最高可设置至 38400*/ #define WDB_TTY_DEV_NAME "tyCo/1" #define CONSOLE_TTY 0

引导行为#define DEFAULT_BOOT_LINE \ "fd=0,0（0,0）hostname：/fd0/vxWorks h=222.1.5.169 e=222.1.5.36 u=VxMe"

2 生成目标文件 bootrom.sys和VxWorks同网络连接。3 制作启动软盘 同网络连接。同时要把 Tornado\target\config\pc486\VxWorks 拷贝至软盘。4 配置主机环境不需要。5 用启动软盘启动目标机将系统制作盘插入目标机软驱，加电启动，目标机即由软盘下载 VxWorks系统。6 从主机搭接（attach）到目标机在 Tornado集成环境中点取 Tools 菜单，选取 Target Server，选择 config...；在Configure Target Servers窗口中先给目标服务器命名；在Configure Target Servers窗口中先给目标服务器命名；

在配置目标服务器窗口中的" Target Servers Property"窗口中选择 Back End，在"Available Back"窗口中选择 wdbserial，再在"Serial Port"窗口中选择主机与目标机连接所占用的串口号（COM1,COM2)，再在"Speed(bps)"窗口中选择主机与目标机间串口速率；在配置目标服务器窗口中的" Target Servers Property"窗口中选择 Core File and Symbols，选择 File为BSP目标文件所在目录（本例为 PC486目录）的VxWorks，并选取为All Symbols；在配置目标服务器窗口中的" Target Servers Property"窗口中的其它各项可根据需要选择；点击 Launch 按钮，连接主机和目标机，全部出现 successed后即可进入应用程序调试；点击图形按钮中下拉框，选择和主机相连的目标机。即可建立主机目标机连接。这时 Shell、Debugger等按钮可用

--------------------------------------------------------------------------------编辑 发表於：2002-01-10 - 12:55:22 IP: 211.97.*.*

--------------------------------------------------------------------------------《嵌入式实时操作系统VXWORKS及其开发环境 TORNADO》第七章实例分析的源代码：================================================================================/*******************************************************************************/#include "vxWorks.h"#include "semLib.h"#include "taskLib.h"#include "msgQLib.h"#include "wdLib.h"#include "logLib.h"#include "tickLib.h"#include "sysLib.h"#include "stdio.h"

/* defines */#if TRUE#define STATUS_INFO#endif

#define MAX_MSG 1#define MSG_SIZE sizeof (MY_MSG)#define DELAY 100

#define HIGH_PRI 150#define LOW_PRI 200

#define TASK_HIGHPRI_TEXT "Hello from the 'high priority' task"#define TASK_LOWPRI_TEXT "Hello from the 'low priority' task"

/* typedefs */typedef struct my_msg{int childLoopCount;char * buffer;} MY_MSG;

/* globals */SEM_ID semId;MSG_Q_ID msgQId;WDOG_ID wdId;int highPriId;int lowPriId;int windDemoId;

/* forward declarations */LOCAL void taskHighPri (int iteration);LOCAL void taskLowPri (int iteration);

/********************************************************************************* windDemo - parent task to spawn children** This task calls taskHighPri() and taskLowPri() to do the actual operation* of the test and suspend itself.* Task is resumed by the low priority task.**/

void windDemo(int iteration)

{int loopCount = 0;

#ifdef STATUS_INFOprintf("Entering windDemo\n");#endif

if (iteration == 0)iteration = 10000;

/* Create objects used by the child tasks */msgQId = msgQCreate(MAX_MSG, MSG_SIZE, MSG_Q_FIFO);semId = semBCreate (SEM_Q_PRIORITY, SEM_FULL);wdId = wdCreate ();

windDemoId = taskIdSelf ();

FOREVER{/* spawn child tasks to exercise kernel routines */highPriId = taskSpawn ("tHighPri", HIGH_PRI, VX_SUPERVISOR_MODE, 4000,(FUNCPTR) taskHighPri, iteration, 0, 0, 0, 0, 0, 0, 0, 0, 0);lowPriId = taskSpawn ("tLowPri", LOW_PRI, VX_SUPERVISOR_MODE, 4000,(FUNCPTR) taskLowPri, iteration, 0, 0, 0, 0,0, 0, 0, 0, 0);taskSuspend (0);

#ifdef STATUS_INFOprintf("\nParent windDemo has just completed loop number %d\n",loopCount);#endif

loopCount ++;} /* end of FOREVER */} /* end of windDemo */

/********************************************************************************* taskHighPri - high priority task** This task exercises various kernel functions. It will block if the resource* not avaiable and relingish the CPU to the next ready task.

**/

LOCAL void taskHighPri(int iteration){int ix;MY_MSG msg;MY_MSG newMsg;

for (ix = 0; ix < iteration; ix ++){/* take and give a semaphore - no context switch involved */semGive (semId);semTake (semId, 100);

/** take semaphore - context switch will occur since semaphore * is unavaiable*/semTake (semId, WAIT_FOREVER);

taskSuspend (0);

/* build message and send it */ msg.childLoopCount = ix;msg.buffer = TASK_HIGHPRI_TEXT;

msgQSend (msgQId, (char*) &msg, MSG_SIZE, 0, MSG_PRI_NORMAL);

/* * read message that this task just sent and print it - no context* switch will occur since there is a message already in the queue*/msgQReceive (msgQId, (char *) &newMsg, MSG_SIZE, NO_WAIT);

#ifdef STATUS_INFOprintf("%s\n Number of iterations is %d\n",newMsg.buffer, newMsg.childLoopCount);#endif

/** block on message queue waiting for message low priority task context* switch will occur since there is no message in the queue. when message* is received, print it*/msgQReceive (msgQId, (char *) &newMsg, MSG_SIZE, WAIT_FOREVER);#ifdef STATUS_INFOprintf("%s\n Number of iterations by this task is %d\n",newMsg.buffer, newMsg.childLoopCount);#endif

/* test watchdog timer */wdStart (wdId, DELAY, (FUNCPTR) tickGet, 1);

wdCancel (wdId);}} /* end of taskHighPri() */

/********************************************************************************* taskLowPri - low priority task* * This task runs at a lower priority and is designed to make available * the resouces that the high priority task is waiting for and subsequently* unblock the high priority task**/

LOCAL void taskLowPri(int iteration){int ix;MY_MSG msg;

for (ix=0; ix {semGive (semId);

taskResume (highPriId);

/* build message and send it */msg.childLoopCount = ix;

msg.buffer = TASK_LOWPRI_TEXT;msgQSend (msgQId, (char *) &msg, MSG_SIZE, 0, MSG_PRI_NORMAL);taskDelay(60);}

taskResume (windDemoId);}

vxworks下 bsp制作教程1 vxworks 概述vxworks是WIND RIVER 公司的产品。作为一种商用的嵌入式操作系统?vxworks 拥有强大的功能和友好的用户界面。与免费的嵌入式操作系统相比?商用操作系统经过严格的测试?具有良好的实时性?易用性和大量的文档支持?但是它的源码是不公开的并且价格昂贵;免费的嵌入式操作系统有很多?大都是 linux的移植?公开源代码?但缺乏文档?要对照源码进行开发。2 BSP的流程BSP流程分成两部分。首先是位于 BootRom中的 Boot代码?它的作用是实现配置硬件和启动 vxworks下载程序。接下来是下载后跳转到 vxworks的入口地址运行操作系统和应用程序。流程入图:

ROM中的启动代码部分:

RomInit在文件在文件 romInit.s中。它是运行的开始?实现这一部分是首先的。它实现判断启动类型?配置内核和非内核寄存器以及内存和外围设备的读写时序?因此可以在此处加入内存检测功能。在 BSP中无法进行调试?只能通过闪灯实现云信正确与否的判断。闪灯功能函数也要在此加入。判断启动类型和配置寄存器?这一部分不需要改动。配置内存和外围设备读写时序?要进行改动。这一部分的 SDRAM?ROM?FLASH?FPGA

有相应的模板可以参考。它的实现是通过使用宏定义来实现的。但是要改动的话也不难?一般是改动空间大小的屏蔽位?读写位数?以及片选寄存器OR和 BR。至于特殊外设的读写有待讨论。内存检测在这里实现较复杂?它根据相应的内存检测算法实现。主要是对地址线和数据线的检测。通过写入数据再会读出数据来判断。使用"走步 1"和"走步 0"

算法。这一部分较多的依赖硬件?可移植性较差?根据自己的单板改动。闪灯在这一部分是强烈推荐的。因为闪灯才能定位程序的运行位置。闪灯函数可移植?一般要改动?因为灯可能接在不同的 I/O口上。另外注意 860SAR的 PORT B

是 32 位的。具体的端口见相应的 CPU的 I/O口的参数?配置相应的寄存器。RomInit在函数结尾跳入 RomStart。RomStart在 BootInt.c 文件中。它是系统运行的第一个 C 函数。这一部分是Wind River 公司提供的标准程序?一般不需改动。该函数是 C的入口函数，由汇编程序调用，主要完成清内存，将 ROM中的程序拷贝到 RAM，解压并跳至解压后的程序处运行。UsrInit在 BootConfig.c 文件中。它主要是实现硬件的初始化。其中涉及

到串口?网口的初始化?CONSOLE的配置等。其中串口和网口的配置是 BSP的重要部分?但 860CPU对串口和王口有很好的支持?只要做很小的改动即可?串口很简单?网口较复杂一些。UsrRoot在 BootConfig.c 文件中。它主要是实现 vxworks 文件的下载?并且跳转到 vxworks的入口地址。从而进入到操作系统中去。VXWORKS 文件中的代码部分:

SysInit在 sysAlib.s中。它是 vxworks的启动代码。它与 RomInit的作用相同?对于这个文件?我们一般不需要去改动它。UsrInit在Usrconfig.c中。它的作用与 Boot中的UsrInit的作用相同?

他们都调用 SysLib.c中的子函数。实现相同的硬件初始化功能。UsrRoot在UsrConfig.c中。它的作用与 Boot中的UsrRoot的作用类似。但是这里的UsrRoot是最终进入到应用程序中去。

-用开始写的驱动程序的文档替代此文档. -从该设备的概要开始.指出该驱动实现整个设备的部分还是全部细节. -描述所有该设备的操作模式,指出该驱动所实现的是哪种. -写出该设备在BSP中创建和初始化的步骤.写出可把该驱动定制为特殊硬件环境的所有宏(macros). -写出所有可帮助用户理解该设备如何工作和设备的接口. 模板概要: 这是一个串口驱动模板.可用来作为写 Vxworks5.3 或更新版本的新驱动的起点. 这些驱动支持旧串口驱动没有的新功能,首先,它们提供一个设置硬件选项的接口;例如,停止位数,数据位,奇偶,等等. 其次,它们提供可用来提供串口线上的外部模式调试(如,ROM 监视器调试)的轮巡通讯(polled communication)接口.通常只支持异步模式驱动. 贯穿整个文件,单词"template"用来替换一个真实的设备名,按惯例采用厂商名的第一个字母加产品编号.例如,Zilog 8530 串口设备应有一个名为Z8530——DUSAART数据结构，好过 TEMPLATE_DUSART. 数据结构 设备数据结构在文件 h/drv/sio/templateSio.h里定义。一个数据结构——TEMPLATE_CHAN被定义，为每个通道。具有多串口通道的设备也为整个芯片定义了一个数据结构.例如，此驱动有一个芯片级的，有两个通道结构作为成员数据结构叫 TEMPLATE_DUSART。 回调 传输准备就绪(transmitter ready)中断调用服务采用回调至高层库以获得一个字符来传送。 默认地，此驱动安装不做任何事情的傀儡回调程序。使用此驱动的高层库(例如,ttyDrv)将用 SIO_INSTALL_CALLBACK控制命令(ioctl command)安装自己的回调程序. 同样，一个接受中断处理采用回调来将字符传给高层库。 模式 理想模式下该驱动应支持轮巡和中断模式，并可动态切换模式。但这并非必须。Vxworks可支持此设备上的 tty设备,即使该驱动只支持中断模式.

增加动态模式切换允许当信息送至时将外部代理激活(例如，在第一桢时中断). 对允许动态模式切换的驱动，注意驱动将在其输入 ISR中间被要求切换模式.一个驱动的输入 ISR 看起来应如此: inChar = *pDev->dr;/@ 从数据寄存器里读一个字符 @/ *pDev->cr = GOT_IT;/@ 承认中断@/ pDev->putRcvChar (...);/@ 发送字符到高层 @/ /@ give the character to the higher layer @/ 如果该通道用作外部模式调试的通讯路径,且接收的该字符是"帧结束"字符，则代理的回调会锁定中断，切换设备到轮巡模式,并使用轮巡模式下的设备片刻.此后代理会解锁中断，切换模式到中断模式，并返回 ISR. 特别地，回调能使两模式切换，首先到轮巡模式然后到中断模式，后返回. 这要求小心处理中断处理内的回调。例如，在调用回调前你必须先承认中断。 用法: 该驱动通常为BSP调用.该模块里直接调用程序是 templateDevInit(), templateDevInit2(),templateIntRcv(), templateIntTx(), and templateIntErr(). BSP调用 templateDevInit()来初始化或重启芯片.它用 intConnect()连接中断处理(templateIntRcv, templateIntTx,和 templateIntErr). 连接中断处理后，BSP调用 templateDevInit2()来告诉驱动中断模式操作已可行.

BSP: 按常规所有BSP特定的串口初始化在 sysSerial.c(被 sysLib.c包含)里进行, sysSerial.c实现至少 4个函数:sysSerialHwInit(),sysSerialHwInit2(), sysSerialChanGet(),和 sysSerialReset(),如下工作: sysSerialHwInit被 sysHwInit调用来初始化串口设备.此程序将在调用能复位设备及安装驱动函数指针的 templateDevinit前初始化 TEMPLATE_DUSART 结构的所有板特定的区域(如,寄存器的 I/O地址，等等).sysSerialHwInit还将执行其他所有串口驱动所需要的过程，比如适当配置板上的中断控制器. sysSerialHwInit2被 sysHwInit2调用来用 intConnect连接驱动的中断处理.连接好中断处理后，templateDevInit2的调用允许中断模式操作开始. sysSerialChanGet被 usrRoot调用来取得与串口通道号相关的串口通道描述.该程序使用一个 0-NUM_TTY之间的一个数为单一的参数.它返回一个指向相应通道描述——SIO_CHAN * 的指针,它正好是 TEMPLATE_CHAN 结构的地址. sysSerialReset被 sysToMonitor()调用且会复位串口设备到一个不活动的状态. 该驱动可通过重定义 TEMPLATE_REG_READ和 TEMPLATE_REG_WRITE 宏来定制.这两个宏用来访问实际的芯片.如不定义，源代码会假定用对所有寄存器的 read/write 访问来对设备进行简单内存映射. 测试: 中断驱动接口可用通常方法来测试.当它(测试信息,译者如是猜测)来到时Vxworks打印到串口控制台,于是看到加电后VxWorks 输出表示该驱动基本开始工作. VxWorks的 Portkit 测试也可用来进行更严格的测试. 轮巡接口容易被检验——你可调用通道的 SIO_MODE_SET ioctllai使它进入轮巡模

式.注意通常的打印工具不能在轮巡模式下与串口通道一起工作.一些代理必须执行轮巡循环来处理基于字符的字符输入/输出.这不是自动进行.当切换 WDB 串口线到轮巡模式时，WDB代理执行它自己的轮巡循环. 动态模式切换可用 tornado工具来检查.重新配置代理使用WDB_COMM_UDLP_SLIP通讯路径(详见VxWorks run_time Guide的配置章节). 如下开始wtxtcl %wtxtcl 从 tcl提示符,连接到 target server: wtxtcl.ex> wtxToolAttach 通知代理来转换外部模式检查回应是OK(0). wtxtcl.ex>wtxAgentModeSet 2 0 要求代理挂起系统(请求会以中断模式传到，但回应会以轮巡模式被传送): wtxtcl.ex>wtxContextSuspend 0 0 0 在此时目标将被挂起.控制台将显示冻结(如果板卡有一个控制台设备),你不能"ping"目标的网络接口. 恢复目标: wtxtcl.ex>wtxContextResume 0 0 0 现在目标将重新运行，于是你能敲信息到控制台(如果板卡有一个控制台设备)并可从主机"ping"目标的网络接口.

关于 RAM_HIGH_ADRS & RAM_LOW_ADRS

我在 bsp developer"s kit 里，RAM_HIGH_ADRS是这样讲的， it is usually the on-board

memory start address plus 0x00100000.This must be the same value as defined in the

Makefile.但在我的 pc486里，#define RAM_HIGH_ADRS 0x00008000

#define RAM_LOW_ADRS 0x00108000 也 就 是 说 RAM_HIGH_ADRS 值 与RAM_LOW_ADRS swap 了，我的问题是有没有人知 道， RAM_LOW_ADRS 和RAM_HIGH_ADRS 这两个值究竟是怎样算出来的，

0x00108000 总不是随便写的吧？

关于RAM_HIGH_ADRS & RAM_LOW_ADRS 虽然不是一定要这个值，但也不是随便写的。 RAM_HIGH_ADRS - bootrom 启动地址； RAM_LOW_ADRS - vxWorks 启动地址；

注意 bootrom和 vxWorks的关系：bootrom 仅仅起引导 vxWorks的作用， 但它同时也是一种特殊的VxWorks应用程序。vxWorks才是你的最终 程序，以后把 vxWorks 放到 ROM/FLASH中后，就不需要 bootrom了。 bootrom 从 ROM中执行（对于 PC，是 boot sector 装载 bootrom.sys）， 起始地址为ROM_TEXT_ADRS（PC上是 0x8000），然后它把自己拷贝到 RAM_HIGH_ADRS（对于 PC，还是 0x8000）。如果 bootrom是压缩的（未 压缩的叫 bootrom_uncmp），则 boorom 先把自己未压缩的部分拷贝到 RAM_LOW_ADRS（PC上是 0x108000），再把自己解压到 RAM_HIGH_ADRS。 以后 bootrom将把 vxWorks加载到 RAM_LOW_ADRS。vxWorks 启动后，bootrom 消失。所以把 bootrom 放到高地址处，而 vxWorks 放到低地址处比较合理。 理解这个过程，再结合 PC机的特殊情况，各种参数就不难理解。 由于 PC上 640K-1M之间的物理地址实际已经分配给 I/O（历史原因）， 所以内存空间存在一个洞。而一般 bootrom程序较小（<640K，严格说是 603K， 因为开始处要放中断向量表等），所以把 bootrom 放到低端内存中。而 vxWorks 一般比较大，放到高端内存中。所以出现RAM_LOW_ADR>RAM_HIGH_ADRS的 现象。另一方面，如果 vxWorks<603K，也可以加载 bootrom 到高端内存， vxWorks 到低端内存（640K之内），这样不会让 640K 内的内存浪费。 （参考 bsp下的Makefile：bootrom_high和 vxWorks_low）。 值得注意的是，vxWorks_low 只管理 640K 内的内存（sysMemTop()返回0xA0000）， 所以可能有些模块会分配不到足够的内存，导致失败。也许可以在内核 启动后，立即调用memAddToPool()将高端内存加进来。 RAM_HIGH_ADRS（0x8000）：由于BIOS约定，将 512 字节引导扇区加载到0x7c00。 RAM_LOW_ADRS（0x108000）：从 1M开始 0x8000大小的块用作起始堆栈，代码 段从 0x108000开始。 参考：VxWorks Programmer"s Guide，D.4，VxWorks Memory Layout。 vxfree@sina.com

>>>以后把 vxWorks 放到 ROM/FLASH中后，就不需要 bootrom了 是这样的吗？应该是说 bootrom和 vxworks build 再一起了才对吧？否则对于 rom ，ram 的初始化哪里去做？ ※ 作 者: serf 02-4-18 上午 09:03:57 ※当然是这样的，看来你还没理解 bootrom是什么。 bootrom 只是一个特殊的 vxWorks，它的功能就是要加载正常的 vxWorks。而“正常的”vxWorks的功能正是你要写的程序。一般将bootrom烧到 ROM/FLASH中，难道

不可以直接把 vxWorks烧在里面吗？ (最终)为什么要同时把 bootrom和 vxWorks都烧进去呢？ ※ 作 者: vxfree 02-4-18 下午 04:16:34 bootrom包含 bootInit.s，它做CPU 初始化，RAM 初始化。。。 bootrom加载的 vxWorks是不包含 bootInit.s的。 没有 bootrom时，ROM版本的 vxWorks叫 vxWorks_rom，它是包含 bootInit.s的。请参考相关的Makefile。另外不要把 bootrom和BSP搞混淆。 ※ 作 者: vxfree 02-4-18 下午 04:22:58 那么就是说在 standard bsp build 菜单下选择 vxworks_rom.hex就可以不去理会bootrom和 vxworks，vxworks_rom.hex里含有 bootInit.s？可以这样理解么？ 》》》bootrom 只是一个特殊的 vxWorks 我理解 bootrom是个特殊的 bsp。因为它实现的是最基本的板极驱动。 而 vxworks是 vxworks的系统文件，vxworks里来定义应用程序的入口 ※ 作 者: serf 02-4-18 下午 05:55:38 ※那么就是说在 standard bsp > build 菜单下选择 vxworks_rom.hex就可以不去理会bootrom和 vxworks，vxworks_rom.hex里含有 bootInit.s？可以这样理解么？ 我用 Tornado 2.0，没有 stardard bsp这个菜单。我估摸是可以这样理解的。 请看 T2下 bootrom，vxWorks和 vxWorks_rom的链接过程： 【bootrom】 ... ld386 -o tmp.o -X -N -e _usrInit \ -Ttext 00008000 bootConfig.o version.o sysALib.o sysLib.o D:\Tornado \target/lib/libPENTIUMgnuvx.a D:\Tornado\host\x86-win32\bin\aoutToBinDec < tmp.o | D:\Tornado\host\x86-win32\b in\deflate > tmp.Z Deflation: 49.98% D:\Tornado\host\x86-win32\bin\binToAsm tmp.Z >bootrom.Z.s ... ld386 -X -N -e _romInit -Ttext 00108000 \ -o bootrom romInit.o bootInit.o version.o \ D:\Tornado\target/lib/libPENTIUMgnuvx.a bootrom.Z.o D:\Tornado\host\x86-win32\bin\romsize 386 -b 00090000 bootrom bootrom: 13408(t) + 179312(d) = 192720 (397104 unused)

【vxWorks】 ... ld386 -X -N -e _sysInit -Ttext 00108000 \ dataSegPad.o partialImage.o -o vxWorks

D:\Tornado\host\x86-win32\bin\vxsize 386 -v 00188000 00108000 vxWorks

vxWorks: 446704(t) + 14168(d) + 23472(b) = 484344 Done.

【vxWorks_rom】 ... ld386 -X -N -e _romInit -Ttext 00008000 -Tdata 00188000 \ romInit.o romStart.o version.o D:\Tornado\target\lib\libPENTIUMgnuvx.a vxWorks.Z.o -o vxWorks_rom D:\Tornado\host\x86-win32\bin\romsize 386 -b 00080000 vxWorks_rom vxWorks_rom: 712(t) + 461080(d) = 461792 (62496 unused) D:\Tornado\host\x86-win32\bin\hexDec -a 0 vxWorks_rom \ > vxWorks_rom.hex

Done.

看清楚了吗？其实你每次执行编译，都有类似信息，不知注意到没有。

> 》》》bootrom 只是一个特殊的 vxWorks > 我理解 bootrom是个特殊的 bsp。因为它实现的是最基本的板极驱动。 > 而 vxworks是 vxworks的系统文件，vxworks里来定义应用程序的入口 我不这样认为。BSP主要包含 romInit.s, sysLib.c, sysALib.s等文件， （有时，您的供应商可能只提供了二进制版本） 主要提供初始化硬件，以及向操作系统提供控制硬件的方法。VxWorks 下没有什么系统文件和一般文件之分，用户程序是要和OS 链接在一起的。 也没有特殊的 bsp，bsp就是 bsp，BSP是一些文件的集合。 而 vxWorks image有版本之分，一个特殊版本就是 bootrom， 它的应用层是已经写好的引导程序。一般情况下，BSP开发人员会做一个 bootrom，但 BSP和 bootrom的概念还是不一样的。 这么理解吧： bootrom = BootStrap1 + BSPpart + OS + BootProgram vxWorks = BSPpart + OS + UserApp vxWorks_rom = BootStrap2 + BSPpart + OS + UserApp

其中： BootStrap1 = romInit.o + bootInit.o BootStrap2 = romInit.o + romStart.o BSPpart = sysLib.o + sysALib.o + ...

OS = lib[CPU]gnuvx.a BootProgram = bootConfig.o UserApp = usrAppInit.o + [your code]

当然 bootInit.o也是根据BSP的文件生成的。 另外命令行下make生成的 vxWorks和这里还稍有不同。