Overview l After development is completed you may

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

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

Autoscaling Vx. Works l The project facility contains an Auto Scale feature which scales Vx. Works based on user application code. l Access via Project => Auto Scale. . . or context menu Auto Project => Auto Scale. . . item on Workspace Builds tab. Scale. . . l First locates Vx. Works components required by your BSP or application; then looks for included components which might not be needed by your application. l Auto Scale can only detect direct references to Vx. Works 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. l Provides an easy, quick start scaling Vx. Works. ® 13 -4

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

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

4. Vx. Works Build Targets l The Project Facility can build the following Vx. Works images in a bootable project: – vx. Works_rom. Compress – vx. Works_rom. Resident l These are listed in the drop-down list on the Rules tab of the projects build spec Properties dialog. l The rule selected in the drop down list is the default rule which is built in a Build Project or Re-Build All. ® 13 -7

ROMable Images l ROMable images contain bootstrap code which copies Vx. Works from ROM to RAM, decompressing if necessary. l The bootstrap code is target/config/comps/src/rom. Start. c, . c which is shared by all ROMable and ROM resident projects. l vx. Works_rom contains an uncompressed, and vx. Works_rom. Compress a compressed, Vx. Works image, built using the vx. Works rule. vx. Works l S-record hex format images are automatically built as vx. Works_rom. hex or vx. Works_rom. Compress. hex ® 13 -8

Compressed ROMable Startup ® 13 -9

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

“Downloadable” Image l The vx. Works image does not contain within it the bootstrap code to copy itself out of ROM into RAM. l 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. l The standard Vx. Works boot program which does this is a specialized Vx. Works application, coming in several variants: bootrom, bootrom_uncmp, and bootrom_res. res l The boot program may not currently be built with the project facility. It must instead be configured and built using the traditional BSP mechanism. ® 13 -11

Standard bootrom Program, A ® 13 -12

Standard bootrom Program, B ® 13 -13

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

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

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

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 rom. Start. c or boot. Init. c – Copy text/data segment(s) to RAM, clear other RAM. Decompress if necessary. 3. usr. Init( ) in prj. Config. c or boot. Config. c – Do pre-kernel hardware & software initialization; start kernel by calling kernel. Init( ). 4. usr. Root( ) in prj. Config. c or boot. Config. c – Initialize facilities configured into Vx. Works; start boot program or user application 5. Boot program or user application. ® 13 -17

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 prj. Config. c 4. usr. Root( ) in prj. Config. c 5. User application. ® 13 -18

Summary 1. Scale Vx. Works using the project facility. Auto Scale may be helpful. 2. Define application start-up code by editing the stub usr. App. Init() in usr. App. Init. c in the project directory. 3. Link you application with Vx. Works 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” Vx. Works images in the project facility. When required, 5. Rebuild boot ROMs in the BSP using the traditional build mechanism. ® 13 -19