Chapter 14 Reconfiguring Vx Works Wind River Systems

Chapter - 14 Reconfiguring Vx. Works ã Wind River Systems, Inc. 1997

Overview · · 2 After development is completed, you may need to: · Exclude unneeded Vx. Works facilities. · Link application code into Vx. Works. · Modify Vx. Works’s start-up code to spawn application tasks. Final application may be: · Downloaded from host over a network. · Linked with Vx. Works and put into ROM. · Loaded from a local disk.

Typical Steps 1. Exclude unneeded facilities from Vx. Works. 2. Modify system start-up code to spawn a task to initialize your application. 3. Modify the target’s Makefile to link your application code with Vx. Works. 4. Run make to produce either a downloadable or a ROM-able application. 3

1. Scaling Vx. Works · · · 4 To build a Vx. Works image which includes a facility, the facility‘s corresponding macro(s) must be defined in either: · wind/target/config/all/config. All. h (generic base configuration avoid modifying this file if possible). · wind/target/config/bsp. Name/config. h (board-specific configuration). Alternatively, Wind. Config can be used to select or unselect Vx. Works facilities. When the new Vx. Works image is built and booted, it will initialize the facilities selected.

Configuration Dependencies · · · 5 Some optional facilities depend on others (e. g. , the NFS facility requires RPC). wind/target/src/config/usr. Depend. c checks these dependencies and includes all required facilities. As a result of dependency checking, some facilities which apparently were excluded may actually be included in the final system image.

2. Modifying System Start-up Code · usr. Root( ) in usr. Config. c: · Executed by first Vx. Works task. · Initializes system facilities. · Start user application if macros defined appropriately: void usr. Root (. . . ) {. . . #ifdef INCLUDE_USER_APPL /* Start the user’s application */ USER_APPL_INIT; /* must be valid C statement */ /* or block */ #endif } 6

Example USER_APPL_INIT · · Define INCLUDE_USER_APPL Define USER_APPL_INIT to be a statement or block which starts your application. You may make necessary declarations within the block: /* mv 162/config. h - Motorola MVME 162 header */. . . #define INCLUDE_USER_APPL #define USER_APPL_INIT { extern void my. App (void); task. Spawn (“t. My. App”, 60, 0, 30000, (FUNCPTR) my. App, 0, 0, 0); }. . . 7

3. Linking An Application with Vx. Works · Modify the Makefile in the target directory: MACH_EXTRA = my. Code. o. . . my. Code. o: . . . $(MAKE) -f Makefile_my. Code. . . · Alternatively, specify your application’s modules on the command line with ADDED_MODULES: % make -f Makefile_mycode % make ADDED_MODULES=my. Code. o vx. Works_rom 8

4. Building Vx. Works · · 9 Use makefile in target directory to rebuild Vx. Works or boot ROM’s: · Go to the target directory. · make object Common makefile objects: vx. Works Vx. Works image (default). vx. Works_rom. hex ROM-able Vx. Works image. vx. Works_res_rom_nosym ROM-resident version of Vx. Works without symbol table. Starts fast, uses little RAM. bootrom. hex Boot ROM code.

ROMable Objects · · · 10 ROMable objects copy themselves into RAM before running. Most of the ROMable vx. Works objects are compressed. An exception to this is vx. Works_rom. If using large capacity ROM’s, may need to modify the constant ROM_SIZE in both: · wind/target/config. h · wind/target/config/target/Makefile Make will fail if the object is larger than ROM_SIZE.

Downloadable Objects · · 11 ROM boot code copied into RAM at RAM_LOW_ADRS, bootstrap part decompresses rest to RAM_HIGH_ADRS. Vx. Works system image loaded at RAM_LOW_ADRS (typically 0 x 1000).

Rebuilding Boot ROM’s · · · 12 If system image is large (>570 Kbytes, typically), downloading will overwrite the booting code, failing while printing: Loading. . . 400316 + 28744 + 23852 May need to change RAM_HIGH_ADRS in: · wind/target/config. h · wind/target/config/target/Makefile New ROM’s are also required to boot from a local disk.

Standard make Targets · · · 13 Not all BSP’s will support all of these images. Some BSP’s support additional images. Standalone Vx. Works has a target shell and built-in symbol table. target/h/make/rules. bsp has the make rules for these images.

Additional Configuration · · 14 Many other configuration changes are possible: · Change the default boot line in config. h. · Change boot code in boot. Config. c. · Modify I/O system parameters in config. All. h. For details, see the Configuration chapter in the Programmer’s Guide.

ROM-based Vx. Works Start-up 1. _rom. Init in config/bsp. Name/rom. Init. s · Minimal initialization: mask interrupts, disable caches, set initial stack, initialize DRAM access. 2. rom. Start( ) in config/all/boot. Init. c · Copy text/data segment(s) to RAM, clear other RAM. Decompress if necessary. 3. usr. Init( ) in boot. Config. c or usr. Config. c · Do pre-kernel hardware & software initialization; start kernel by calling kernel. Init( ). 4. usr. Root( ) in boot. Config. c or usr. Config. c · Initialize facilities configured into Vx. Works; start boot program or user application 5. Boot program or user application. 15

Downloaded Vx. Works Start-up 1. Boot program loads Vx. Works over network, from local disk, etc. . Call: 2. _sys. Init in config/bsp. Name/sys. ALib. s · Similar to _rom. Init: mask interrupts, disable caches, set initial stack pointer. Then call: 3. usr. Init( ) in config/all/usr. Config. c 4. usr. Root( ) in config/all/usr. Config. c 5. User application. 16

Summary 1. Modify config. h to exclude unneeded facilities. 2. Define INCLUDE_USER_APPL and USER_APPL_INIT to make usr. Root( ) spawn your tasks. 3. Modify the Makefile to link your application into the Vx. Works system image. MACH_EXTRA = my. Code. o. . . 4. Remake the system image. New image can be booted or ROM-ed. % make vx. Works_rom. hex % make bootrom. hex 17