EEPW论坛

Introduction to VxWorks -------------------------------------------------------------------------------- VxWorks, from Wind River Systems, is a commercial operating system for embedded real-time applications. It is the standard real-time operating system in the FST for embedded VME-based flight software and simulation development. VxWorks is "UNIX-friendly"--that is, it interoperates nicely with the UNIX environment and provides for many of the UNIX C-library routines, like file I/O, sockets, RCP, etc. VxWorks supports concurrent tasking--workstations communicating with each other by exchanging messages. VxWorks is multi-threaded and supplies all intertask messaging functions, including semaphores, pipes, sockets, and TCP/IP interprocessor communications. The VxWorks socket utilities provide the hardware interface portions of the device drivers for the Ethernet connection between the "flight" processor and hardware dynamics simulation. VxWorks supports disk- and network-based filesystems. VxWorks supports remote debugging from workstations. VxWorks is not part of the bundled operating system: as an unbundled software package, it is automounted on /opt and it will not be seen unless it is being used. The contents of the /opt directory, as well as links to all /opt-mounted software can be found under /usr/local/auto/opt. -------------------------------------------------------------------------------- Current VxWorks version and the boards supported: vxworks-5.1.1.......... hkv4f vxworks-5.2............. hknitro vxworks-5.2.ppc ..... mv1600 -------------------------------------------------------------------------------- 编辑 发表於：2002-01-01 - 12:04:28 IP: 210.53.80.18 -------------------------------------------------------------------------------- Compiling for VxWorks Targets -------------------------------------------------------------------------------- This section outlines compiling user applications for VxWorks. If you need to compile a kernel, please see the Kernel configuration section. The FST currently supports m68k, mips, powerpc, rad6000 sparc architectures for VxWorks version 5.1.1 and/or version 5.2. The directory /usr/local/bin contains the commands you will need to compile and link programs for these targets. In general, GNU compiler tools distributed by Wind River Systems are provided as well as well as the GNU tool set distributed by on the internet by FSF and/or Cygnus. In addition, the FST is evaluating compiler tools from Green Hills. Tools built from the GNU distribution are always more up to date and provide some support for C++. The following gives program names for running the compiler tools. You shouldn't need to set any environment variables (e.g., GCC_EXEC_PREFIX, VX_BSP_HOME, etc) to use these unless you are building a kernel. In general, you should include -I/opt/vxworks-5.1.1/h or -I/opt/vxworks-5.2/h as a compiler flag. The Wind River programs for the M68K targets (hkv4f, hknitro) are cc68k - compiler ld68k - linker/loader ar68k - archiver ranlib68k - library generator Compile flags should include -m68040 -DCPU=MC68040 or -m68040 -DCPU=MC68060 The GNU programs for the M68K targets (hkv4f, hknitro) are m68k-gcc - compiler m68k-ld - linker/loader m68k-ar - archiver m68k-ranlib - library generator Compile flags should include the same defined above. Note that the recent versons of the GNU C compilers for VxWorks derive a -DCPU=MC68040 from a -m68040 flag. Hence, you may see warning about CPU being multiply defined. I believe these warnings can be ignored safely. The Wind River's programs for the SPARC targets (sun2ce) are ccsparc - compiler ldsparc - linker/loader arsparc - archiver ranlibsparc - library generator Compile flags should include -DCPU=SPARC The GNU programs for the SPARC targets (sun2ce) are gcc - compiler ld - linker/loader ar - archiver ranlib - library generator Compile flags should include -DCPU=SPARC (???). The Wind Rivers programs for the MIPS targets (hkv3500) are gcc-sde - compiler ld-sde - linker/loader ar-sde - archiver ranlib-sde - library generator Compile flags should include -DCPU=R3000 (???). The GNU programs for the MIPS targets (hkv3500) are mips-gcc - compiler mips-ld - linker/loader mips-ar - archiver mips-ranlib - library generator Compile flags should include -DCPU=R3000 -mcpu=r3000 (???). The GNU programs for the RS6000 (XCOFF objects) targets are rs6000-gcc - compiler rs6000-ld - linker/loader (doesn't quite work yet - M.Wette) rs6000-ar - archiver rs6000-ranlib - library generator We are experiencing some problems with the linker. Also, some object files from the assembler seem to have problems. The GNU programs for the PowerPC targets (ELF objects) (mvme1603) are ppc-gcc - compiler ppc-ld - linker/loader ppc-ar - archiver ppc-ranlib - library generator The PowerPC is supported for VxWorks version 5.2 only. This compiler does not yet work w/ the VxWorks distributions we have because the output format is not ELF format and not the extended DWARF format. The root VxWorks distribution is in /opt/vxworks-5.1.1. The hknitro distribution (a post 5.1.1 release) is in /opt/vxworks-hknitro. The include files for VxWorks 5.1.1 are in /opt/vxworks-5.1.1/h. The libraries are in /opt/vxworks-5.1.1/lib If you want to compile packages (e.g., TCL) ported to VxWorks you may want (or need) to include the following include and link flags: -I/opt/m68040-vxworks5.2/include -L/opt/m68040-vxworks5.2/lib -I/opt/r3000-vxworks5.2/include -L/opt/r3000-vxworks5.2/lib If you want to compile your programs against the FST prototype tools (e.g., Tramel, Dshell) you should include the following in your compile flags: -I/proj/proto/fst-dev/include and the following in you link flags (or load the corresponding .o files at load time): -L/proj/proto/fst-dev/m68040-vxworks/lib -ltramel -llist ... -L/proj/proto/fst-dev/mips-vxworks/lib -ltramel -llist ... (see TBD for compile/load flags for specific applications). -------------------------------------------------------------------------------- 编辑 发表於：2002-01-01 - 12:05:27 IP: 210.53.80.18 -------------------------------------------------------------------------------- Configuring VxWorks Targets -------------------------------------------------------------------------------- To add a new board you need to build and install a kernel configure a root directory configure the BOOTP daemon to boot the target Compiling a Kernel The task of compiling a kernel requires more work than compiling a user application program. The process for building kernels easily is being worked out. Our plan is to provide shell scripts to copy kernel files into your home directory, let you compile a kernel, and then install it. One gotcha. I had to hack on config/all/usrConfig.c to get VxWorks to NFS mount its root directory. This feature is included in later versions of BOOTP RFCs but is not supported by the current release of VxWorks. So if you want build a new kernel, talk to me or make sure you include the code in /opt/vxworks-5.1.1/config/all.2/usrConfig.c This process will be integrated into the vxkerngen command described below. Compiling a Kernel -- new method Run the function vxkerngen vxkerngen /opt/vxworks-5.2 hkv4f mrw2 the first argument is the VxWorks distribution, the second argument is the BSP, the third argument is a tag you want to use to namek the kernel. Next, make modifications and build the kernel. Once you make any kernel modifications, you should be able to build and install a new kernel using the following commands cd hkv4f.520.mrw2/hkv4f ./make ./install The install command above will copy the kernel to the proper VxWorks boot directory. In the above example, the kernel (VxWorks) would be copied to ~vw/boot/hkv4f.520/mrw2. Installing a Kernel The VxWorks kernel boot files are located in /proj/vw-fst/boot This directory is loopback-mounted onto /tftpboot/vxboot so that the RTCs can get at it via tftp. The kernel files are named using a convention of .. For example, you might find a kernel with the name mrw2 in the directory hkv4f.511 The name hkv4f refers to the board, a Heurikon HKV4F. The 511 means "VxWorks Version 5.1.1" (520 would be version 5.2, 530 for VxWorks5.3/Tornado1.0). The mrw2 is the tag. The README file in the boot directory should explain what that means. If you add a file to the directory be sure to document the kernel in the README file. Installing the kernel file does not make a board boot from that kernel. Ordinarily this is done by pointing the board symbolic link to the kernel you want to boot. There is a script file in the boot directory called setkern, with man page setkern.1, for changing the kernel that a particular target boots from. For example, one could configure target rtc3-0 to boot with the kernel hkv4f.511.2 by doing the following: % cd ~vw/boot % ./setkern rtc3-0 hkv4f.511.2 This script creates symbolic links from rtc1 and rtc1.sym to hkv4f.511.2 and hkv4f.511.2.sym. By convention all VxWorks targets in the FST look for boot files, in the boot directory, which match their name. For example, the target named rtc3-0 boots looking for the files /proj/vw-fst/boot/rtc1 /proj/vw-fst/boot/rtc1.sym -------------------------------------------------------------------------------- The bootptab file The configuration file for bootpd is /etc/bootptab. There is an old copy of this file in /proj/vw-fst/boot if you want to take a look. The remote target boot information (e.g., internet address, hostname, etc.) is kept in here. Take a look. It shouldn't have to be changed to change a boot image. That can be done via setkern described above. This is the file where you add new targets or change internet addresses. If you change this file sent HUP to the bootpd. Root Directory You will probably want a root directory set up for a new board. To do this change to the directory /proj/vw-fst/root and execute the command ./genroot rtcX board vx-version where rtcX is the boards hostname, board is the board type (e.g., hkv4f, hknitro, hkv3500), and vx-vers is the version of VxWorks (e.g., 511) Booting Most of the realtime targets in the testbed are booted via BOOTP. "saturnv" runs the daemon bootpd. The bootp-RTCs in the lab are now configured to use bootp go get the boot file and initial NFS-mounted directory. The root directories for the RTC targets are mounted from the directories /proj/vw-fst/root/rtcX where rtcX is the specific RTC target hostname. Startup Files Users can put their own startup files in /proj/vw-fst/root/rtcX/script where rtcX is the hostname of the RTC. This directory is mode 1777 so everyone can put files in there. On the remote target the script directory hangs off root (i.e., it is /script). For example, I have a script file /proj/vw-fst/root/rtc0/script/mwette.0 which contains nfsMount("atlas2", "/export/home.2/mwette", "/home/mwette"); shellPromptSet("mwette@rtc0> "); cd "/home/mwette" When I reboot log onto rtc0 I just need to type rtc0> < script/mwette.0 and I'm all set to go. Note that there is a separate script directory for each target. -------------------------------------------------------------------------------- 编辑 发表於：2002-01-01 - 12:06:44 IP: 210.53.80.18 -------------------------------------------------------------------------------- Running Programs on VxWorks Targets -------------------------------------------------------------------------------- Hello, World Say you have compiled a program to print "hello, world" (see the section on compiling for VxWorks) and it is sitting in your home directory as hello.o. The program might look like the following #include int hello_world() { printf("hello, world\n"); } To run your program first determine where you home directory resides. My username is mwette so I use the following: % ypmatch mwette auto.home atlas2:/export/home.2/mwette now I log onto the VxWorks target, say rtc0-0, and mount my home directory: % rlogin rtc0-0 rtc0-0> nfsMount("atlas2", "/export/home.2/mwette", "/home/mwette") The next step is to get to my home directory: rtc0-0> cd "/home/mwette" Now I can load my program: rtc0-0> ld < hello.o Now I can run it. Assume that the entry point for my home directory is hello_world. I just type that rtc0-0> hello_world hello, world rtc0-0> Startup Files Users can put their own startup files in /proj/vw-fst/root/rtcX/script where rtcX is the hostname of the RTC. This directory is mode 1777 so everyone can put files in there. On the remote target the script directory hangs off root (i.e., it is /script). For example, I have a script file /proj/vw-fst/root/rtc0/script/mwette.0 which contains nfsMount("atlas2", "/export/home.2/mwette", "/home/mwette"); shellPromptSet("mwette@rtc0> "); cd "/home/mwette" When I reboot log onto rtc0 I just need to type rtc0> < script/mwette.0 and I'm all set to go. Note that there is a separate script directory for each target