1. ® 13-2 Overview After development is completed, you may need to: –Exclude unneeded VxWorks facilities. –Link application code into VxWorks. –Extend VxWorkss start-up code to spawn application tasks. Final application may be: –Linked with VxWorks and put into ROM or flash. –Downloaded from host over a network. –Loaded from a local disk.

2. ® 13-3 1. Scaling VxWorks The Project Facility may be used to configure all VxWorks images (downloadable, ROMable, ROM resident) except for boot ROM images. config.h Boot ROM images must be configured by editing the config.h file for the BSP involved. VxWorks must be rebuilt using the Tornado 1.0.1 mechanism (make in the BSP directory). When the new VxWorks image is built and booted, it will initialize the facilities selected.

3. ® 13-4 Autoscaling VxWorks The project facility contains an Auto Scale feature which scales VxWorks based on user application code. Project => Auto Scale...Auto Scale... Access via Project => Auto Scale... or context menu Auto Scale... item on Workspace Builds tab. First locates VxWorks components required by your BSP or application; then looks for included components which might not be needed by your application. Auto Scale can only detect direct references to VxWorks modules by your application. Indirect references through pointers are not detected, so Auto Scale may suggest a module is unneeded when it really is needed. Provides an easy, quick start scaling VxWorks.

4. ® 13-5 2. Application Start-up Code The file usrAppInit.c is provided containing a stub routine usrAppInit() in every bootable project. application components > application initialization If application components > application initialization is included, then usrAppInit() will be called at startup after VxWorks components have been initialized. Edit usrAppInit() to include code starting your application. Often a single taskSpawn() suffices. void usrAppInit (void) { #ifdef USER_APPL_INIT USER_APPL_INIT; /* for backwards compatibility */ #endif /* add application specific code here */ }

5. ® 13-6 3. Linking An Application with VxWorks Several approaches: –Add application source code to the bootable VxWorks project and build together. –Build application object modules in separate projects, and list these modules in the EXTRA_MODULES makefile macro in the VxWorks project build spec. The modules will be linked with the VxWorks image when it is built. –Build archive(s) containing application modules. Add archive(s) to LIBS makefile macro in VxWorks build spec. VxWorks / usrAppInit() code will be linked against these libraries. Combined approaches are possible.

6. ® 13-7 4. VxWorks Build Targets The Project Facility can build the following VxWorks images in a bootable project: –vxWorks –vxWorks_rom –vxWorks_romCompress –vxWorks_romResident These are listed in the drop-down list in the drop-down list on the Rules tab of the projects build spec Properties dialog. The rule selected in the drop down list is the default rule which is built in a Build Project or Re-Build All.

7. ® 13-8 ROMable Images ROMable images contain bootstrap code which copies VxWorks from ROM to RAM, decompressing if necessary. target/config/comps/src/romStart.c The bootstrap code is target/config/comps/src/romStart.c, which is shared by all ROMable and ROM resident projects. vxWorks_rom vxWorks_romCompress vxWorks vxWorks_rom contains an uncompressed, and vxWorks_romCompress a compressed, VxWorks image, built using the vxWorks rule. vxWorks_rom.hexvxWorks_romCompress.hex S-record hex format images are automatically built as vxWorks_rom.hex or vxWorks_romCompress.hex.

8. ® 13-9 Compressed ROMable Startup

9. ® 13-10 ROM Resident Image vxWorks_romResident vxWorks_romResident is a ROM resident image. It executes out of ROM. This image contains start-up code which copies only the VxWorks data segment into RAM at RAM_LOW_ADRS. It clears RAM in a cold reboot. This image starts faster and uses less RAM than the other ROMable images, but executes more slowly. vxWorks_romResident.hex An S-record hex image is produced automatically in vxWorks_romResident.hex.

10. ® 13-11 Downloadable Image The vxWorks image does not contain within it the bootstrap code to copy itself out of ROM into RAM. It requires a separate boot program to: –obtain the image from a local storage device or from across the network; and –load it into RAM at RAM_LOW_ADRS to execute. bootrom, bootrom_uncmp, and bootrom_res The standard VxWorks boot program which does this is a specialized VxWorks application, coming in several variants: bootrom, bootrom_uncmp, and bootrom_res. The boot program may not currently be built with the project facility. It must instead be configured and built using the traditional BSP mechanism.

11. ® 13-12 Standard bootrom Program, A

12. ® 13-13 Standard bootrom Program, B

13. ® 13-14 Rebuilding Boot ROMs If system image is large, downloading will overwrite the booting code, which may fail while printing: Loading... 400316 + 28744 + 23852 Need to increase RAM_HIGH_ADRS in: –wind/target/config//config.h –wind/target/config/bspName/config.h –wind/target/config//Makefile –wind/target/config/bspName/Makefile –The Project facility configuration for the bootable VxWorks project. New ROMs are also required to boot from a local disk, or other boot devices not configured by default into the boot program.

14. ® 13-15 Traditional VxWorks Configuration The traditional VxWorks configuration mechanism is required for configuring boot ROMs and still available for other builds. target/config//config.h Edit target/config/bspName/config.h to configure VxWorks. –Define the INCLUDE_xxx macro for a component to include it. –Define the values of other parameter macros. target/config/all/configAll.h –Many defaults are defined in target/config/all/configAll.h, and may need to be redefined. Makefile make bootrom Build VxWorks or boot ROM using Makefile in BSP directory, e.g. make bootrom.

15. ® 13-16 Redundant Address Parameters config.h Makefile The following macros are defined in: 1. The bootable project build spec; 2. bspName/config.h; and 3. bspName/Makefile. RAM_LOW_ADRS RAM_HIGH_ADRS They should be kept consistent in all three locations. config.hMakefile Also, the following should be kept consistent in a BSPs config.h and Makefile: ROM_TEXT_ADRS ROM_SIZE

16. ® 13-17 ROM-based VxWorks Start-up 1._romInit in config/bspName/romInit.s –Minimal initialization: mask interrupts, disable caches, set initial stack, initialize DRAM access. 2.romStart( ) in romStart.c or bootInit.c –Copy text/data segment(s) to RAM, clear other RAM. Decompress if necessary. 3.usrInit( ) in prjConfig.c or bootConfig.c –Do pre-kernel hardware & software initialization; start kernel by calling kernelInit( ). 4.usrRoot( ) in prjConfig.c or bootConfig.c –Initialize facilities configured into VxWorks; start boot program or user application 5.Boot program or user application.

17. ® 13-18 Downloaded VxWorks Start-up 1.Boot program loads VxWorks over network, from local disk, etc.. Call: 2._sysInit in config/bspName/sysALib.s –Similar to _romInit: mask interrupts, disable caches, set initial stack pointer. Then call: 3.usrInit( ) in prjConfig.c 4.usrRoot( ) in prjConfig.c 5.User application.

18. ® 13-19 Summary 1.Scale VxWorks using the project facility. Auto Scale may be helpful. 2.Define application start-up code by editing the stub usrAppInit() in usrAppInit.c in the project directory. 3.Link you application with VxWorks by including its files, or specifying its object modules or libraries in the EXTRA_MODULES or LIBS macros. 4.Rebuild ROMable (compressed or uncompressed), ROM resident, or downloadable VxWorks images in the project facility. When required, 5.Rebuild boot ROMs in the BSP using the traditional build mechanism.