05 preKernelBoot PDF

Chapter
5
Pre-Kernel Initialization - Boot Specic Code
Tornado BSP Training Workshop Copyright Wind River Systems Wind River Systems
5-1

5.1 Boot Specic vs. Generic Code
romInit.s : romInit()
PIC and VxWorks

bootInit.c : romStart() sysALib.s : sysInit()
Tornado BSP Training Workshop
Copyright Wind River Systems
Wind River Systems
5-2
VxWorks Image Types and Generic Code

Details of pre-kernel initialization depend on VxWorks image type characteristics:
q
ROM image - Boot or end-user image. a. compressed b. uncompressed ROM-resident image - Boot or end-user image. Loadable image - End-user image.
Generic pre-kernel code common to all image types is usrInit() and the routines it calls. These will be discussed in the next chapter.
Tornado BSP Training Workshop Copyright Wind River Systems
Wind River Systems
5-3
Boot Specic Pre-kernel Initialization Code

VxWorks image type specic code:
q q
romInit() romStart() sysInit()
romInit() and romStart() execute for all images burned into ROM. sysInit() only executes for all loadable VxWorks images. romInit() and sysInit() are similar routines except romInit() initializes memory and sysInit() does not (this is done by romInit() in the boot image).
Wind River Systems
5-4
Choice of First Image

Which type of image is developed rst depends on download path:
q q
Download to RAM - Use vxWorks. Download to ROM - Use vxWorks_rom or vxWorks.res_rom_nosym.
The initial image should not be compressed or contain a symbol table. These features can be added later. The rst image for a download path to ROM:
q
vxWorks_rom - Allows software breakpoints for code which executes in RAM. vxWorks.res_rom_nosym - Provides a smaller RAM footprint (and possibly reduced start-up time).
Wind River Systems
5-5
Note, if the rst image is vxWorks, RAM will need to be initialized prior to the download.

Boot Specic vs. Generic Code 5.2
PIC and VxWorks

Wind River Systems
5-6
romInit() Basics
First code to execute on power-up. Entry point for all VxWorks ROM images. Performs minimum required setup to execute romStart(). The remainder of hardware initialization is performed by generic pre-kernel code. Routine must:
q q
Mask processor interrupts and reset processor. Initialize the memory system. Initialize stack pointer and other registers to begin executing romStart() and passing the boot type.
Routine is written is assembly language and resides in le romInit.s.

5-7
Architecture vs. BSP Specic Issues

Much of what romInit() needs to do is processor specic and can be copied from the reference BSP:
q q
Masking processor interrupts. Initializing on-processor caches. Initializing the stack pointer.
Non-processor specic initialization involves DRAM and will be specic to the hardware environment.
q q
Wait states. Refresh rates. Chip selects (bridge/bus/memory controllers, etc.) Disabling of L2 caches (if necessary).
Wind River Systems
5-8
Usually on-processor caches are disabled except when the instruction cache is turned on for faster Flash/ROM boots.
Cold vs. Warm Boots

Two boot types:
q q
Cold boot - Power-up of hardware environment. Warm boot - Call to reboot(), ^X, or exception at interrupt level. The routine which passes control to the ROM monitor is sysToMonitor() in sysLib.c.
Where romInit() begins execution is a function of the boot type:

q
Cold boot - Execution begins at the entry point romInit(). Boot type is forced to be BOOT_COLD. Warm boot - Execution begins at romInit() plus a small offset (usually 4 bytes). Boot type is saved.
Boot type (cold/warm) is stored in an architecture specic register and passed to romStart().
5-9
The rst instruction executed by romInit() is a branch to a label (cold: or warm:) where the instruction to store the appropriate boot type is. The branch to cold is the rst executable instruction in romInit(), the branch to warm follows this instruction and is where romInit() begins execution for a warm boot. reboot() services ^X.
Stack Pointer Initialization

Macro which congures beginning of stack is STACK_ADRS in congAll.h. For ROM-resident images the stack will begin:
q
In RAM at the start of the VxWorks data segment for stacks which grow down. In RAM at the start of the VxWorks data segment less the size of the stack for stacks which grow up. In RAM at the start of the text segment of the VxWorks image for stacks which grow down. In RAM at the start of the text segment of the VxWorks image less the size of the stack for stacks which grow up.
Copyright Wind River Systems Wind River Systems
For non-ROM-resident images the stack will begin:

q
5-10
romInit() - PIC
romInit(), which runs in ROM/Flash, must be written as Position Independent Code (PIC) to support the various boot strategies for VxWorks images. PIC code is program counter (PC) relative. If a ROM address cannot be made program counter relative then it must be recomputed by:
q q
Subtracting _romInit (The entry point for romInit().) Adding ROM_TEXT_ADRS (Boot ROM/Flash entry address. Where ROM code is burned.)
This algorithm ensures that a ROM address is expressed relative to the PC value for romInit() regardless of the address assigned to romInit() by the compiler/linker.
5-11
Address recalculations are usually done with a macro: #define ROM_OFFSET(x) ((x) - _romInit+ ROM_TEXT_ADRS) Because romInit() is statically linked into a VxWorks image, the address assigned to romInit() by the linker will be a ROM address for a ROMresident image and a RAM address for a non-ROM-resident ROM image. This will be discussed in more detail in the next section.
romInit() - Some dos and donts

Perform minimum necessary initialization. Leave most hardware initialization to generic routine sysHwInit(). Do not call out to other modules or routines:
q q
May cause linking problems for compressed images. Call outs to C routines may use absolute not PC relative addressing.
Make sure romInit() is the rst routine in romInit.s. Start with romInit() from reference BSP. Make sure macros in Makele and cong.h are correct:
q q
ROM_TEXT_ADRS ROM_SIZE
5-12
After romInit() initializes memory, but before branching to romStart(), run memory diagnostic code:
q q
Often supplied by board vendor. Will test for replication of maps (e.g. SIM1 maps to SIM2), missing memory, refreshes, etc. Remove code when test is complete.

Boot Specic vs. Generic Code
5.3
PIC and VxWorks

Wind River Systems
5-13
PIC and VxWorks Builds

romInit() which executes in ROM needs to be PIC to support various VxWorks image types. This is because romInit() is linked into all non-loadable VxWorks images, all of which do not execute in ROM. To understand how romInit() (as well as other routines) are linked into VxWorks images the build rules in ../h/ make/rules.bsp must be examined. Examine the link instructions for vxWorks_rom:
q q
Uncompressed rommable binary image. Begins execution in ROM. Transfers execution to RAM in romStart().
5-14
vxWorks_rom Build
The link instructions for the target vxWorks_rom are:
vxWorks_rom : .... ....
$(LD) $(LDFLAGS) $(LD_PARTIAL_FLAGS) \ -o ctmp.o usrConfig.o \ $(MACH_DEP) version.o $(LIBS) .... $(LD) $(LDFLAGS) -e $(ROM_ENTRY) $(LD_LOW_FLAGS) \ -o $@ romInit.o bootInit_uncmp.o dataSegPad.o \ ctmp.o ctdt.o ....
Dots, .... indicate missing code. Missing code consists of compilation and le management instructions.
5-15
vxWorks_rom Build Link Flags

The rst link builds most of the image and places it in the relocatable module ctmp.o. The second link builds the nal fully linked relocatable image vxWorks_rom (this is target name for $@). The link ags are:
q q
LD = ldppc (make.$(CPU)$(TOOL) ) LDFLAGS = -X -N (defs.bsp) LD_PARTIAL_FLAGS = -X -r (defs.bsp)
Note, it is the -r ag which produces a partially linked relocatable module (ctmp.o) for the rst link, but not for the second which produces vxWorks_rom.
Wind River Systems
5-16
The -X ag deletes all temporary local symbols. The -N ag sets the text and data segments as readable and writable, and does not page-align the data segment. See the GNU ToolKit Users Guide for information on compiler and linker ags.
vxWorks_rom Build - ctmp.o

The temporary relocatable module ctmp.o uses the macro expansions (defs.bsp):
q q
MACH_DEP = sysALib.o sysLib.o .. LIBS = ../lib/lib$(CPU)$(TOOL)vx.a sysInit() - in sysALib.o sysHwInit() - in sysLib.o usrInit() - in usrCong.o
Pre-kernel initialization code in ctmp.o:

q q
Remainder of the ctmp.o contains modules from the appropriate VxWorks library archive and version.o. The remainder of the pre-kernel initialization code is included in the second link.
5-17
congAll.h and cong.h control which VxWorks modules in archived les are linked. Archived les reside in the directory ../lib/ obj$(CPU)$(TOOL)vx. ctmp.o is deleted after the build is completed. The complete macro denitions are:
MACH_DEP LIBS = sysALib.o sysLib.o $(MACH_EXTRA) $(ADDED_MODULES) = $(LIB_EXTRA) $(TGT_DIR)/lib/lib$(CPU)$(TOOL)vx.a
Additional machine dependent modules added by the BSP developer (MACH_EXTRA), application specic modules added by users (ADDED_MODULES), and library archives (perhaps containing third party drivers) are also linked into ctmp.o.
vxWorks_rom Image
The nal link includes the remainder of the kernel initialization code:
q q
romInit() - in romInit.o romStart() - in bootInit_unmcp.o
The nal vxWorks_rom image uses the macro expansions (defs.bsp):

q q
ROM_ENTRY LD_LOW_FLAGS
= _romInit = -Ttext $(RAM_LOW_ADRS)
The ROM_ENTRY macro for the -e ag insures that romInit() will be the execution entry point. The LD_LOW_FLAGS produces text addresses starting in RAM not ROM!
5-18
Note, that this nal link also includes:

q q
dataSegPad.o - For VxVMI page alignment of data segment. ctdt.o - C++ constructors/destructors produced by munch.
The rules for building the module bootInit_uncmp.o (from bootInit.c) are in rules.bsp:
bootInit_uncmp.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o - @ $(RM) $@ $(CP) $(BOOTINIT) bootInit_uncmp.c $(CC) -c $(CFLAGS) -DUNCOMPRESS bootInit_uncmp.c - @ $(RM) bootInit_uncmp.c
The bootInit.c (BOOTINIT) le is simply copied to a le bootInit_uncmp.c and compiled. RAM_LOW_ADRS is the load point of this image in RAM.
vxWorks_rom Image and PIC

The vxWorks_rom image is burned into ROM (or Flash) at the address ROM_TEXT_ADRS (Makele). This is how ROM_ENTRY = ROM_TEXT_ADRS. Execution will begin in ROM even though the linker has assigned RAM addresses to the text for romInit().
This is the reason why romInit() must be PIC code for this image. For addresses which are not program counter relative, address recalculations are usually done with a macro:
#define ROM_OFFSET(x)((x) - _romInit+ROM_TEXT_ADRS)
Wind River Systems
5-19
Note, for some environments ROM_TEXT_ADRS may not be at the beginning of the ROM area if this area is used to store a reset vector. The portion of romStart() which executes in ROM for this image will also need to be PIC.
vxWorks.res_rom_nosym
Next consider a ROM-resident image:
vxWorks.res_rom_nosym: .... $(LD) -o $@ $(LDFLAGS) $(ROM_LDFLAGS) \ -e $(ROM_ENTRY) $(RES_LOW_FLAGS) \ romInit_res.o bootInit_res.o \ ctmp.o ctdt.o
The linker ag RES_LOW_FLAGS expands to:

-Ttext $(ROM_TEXT_ADRS) -Tdata $(RAM_LOW_ADRS)
q
Text is assigned ROM addresses. Data is assigned RAM addresses.
romInit() does not need to be PIC for this image, or any ROM-resident image.
5-20
For exibility with respect to VxWorks builds it is suggested that VxWorks code which executes in ROM be PIC. ROM_LDFLAGS is an optional macro which allows link instructions to be passed to ROM-resident images. It may be dened in Makele. The rules for building romInit_res.o (from romInit.s) and bootInit_res.o (from bootInit.c) are in rules.bsp:
romInit_res.o: depend.$(BSP_NAME) romInit.s romInit.o - @ $(RM) $@ $(CC) $(CFLAGS_AS) -DROM_RESIDENT -c -o $@ romInit.s bootInit_res.o : depend.$(BSP_NAME) $(BOOTINIT) bootInit.o - @ $(RM) $@ $(CP) $(BOOTINIT) bootInit_res.c $(CC) -c $(CFLAGS) -DROM_RESIDENT bootInit_res.c - @ $(RM) bootInit_res.c

PIC and VxWorks 5.4

Wind River Systems
5-21
romStart() Basics
Jumped to by romInit() which places the start type on the stack for romStart(). Performs necessary code relocation, uncompression, and RAM initialization for ROM images:
q q
Copies appropriate ROM image segments to RAM. Clears portions of RAM not being used (cold boot). Performs uncompression if required. Passes control to generic pre-kernel code (usrInit()).
Code is written in C and resides in ../all/bootInit.c. Portion which executes in ROM should be PIC. Do not modify code. Functionality is controlled by conguration macros.
5-22
For i960 processors romStart() transfers control to sysInitAlt() which transfers control to usrInit(). sysInitAlt() re-installs the processor tables for the i960. Code modication during development will be discussed later in this section.
Code Relocation
Which image segments are relocated by romStart():
q q
ROM images - Text and data. ROM-resident images - Data. Uncompressed VxWorks boot - RAM_HIGH_ADRS Compressed VxWorks boot - RAM_HIGH_ADRS Uncompressed VxWorks - RAM_LOW_ADRS Compressed VxWorks - RAM_LOW_ADRS ROM-resident VxWorks boot - RAM_HIGH_ADRS ROM-resident VxWorks - RAM_LOW_ADRS
Final RAM destination for ROM image segments:

q q
For uncompressed ROM images there is only one relocation from ROM to the nal RAM destination.
5-23
Compressed Image Relocations

Compressed ROM images contain an uncompressed component and a compressed component. romInit.s, and bootInit.c code is in the uncompressed component. Remainder of image is compressed. There are two relocations for these images:
q
First relocation moves uncompressed component from ROM to RAM. Second relocation occurs when compressed component of image is uncompressed and relocated from ROM to nal destination in RAM.
Second relocation is performed by romStart() in RAM. romStart() is moved into RAM during rst relocation.
Wind River Systems
5-24
For compressed images, if the second relocation is to RAM_LOW[HIGH]_ADRS the rst relocation will be to RAM_HIGH[LOW]_ADRS.
q
Final (second) relocation addresses for various images are listed on the previous page.
Compressed Binary Images

Compressed VxWorks boot images:
q
Relocate uncompressed component of ROM image to RAM location RAM_LOW_ADRS. Uncompression code executes in RAM uncompressing and relocating VxWorks boot image from ROM to RAM location RAM_HIGH_ADRS. Execution jumps to usrInit(). Relocate uncompressed component of ROM image to RAM location RAM_HIGH_ADRS. Uncompression code executes in RAM uncompressing and relocating VxWorks image from ROM to RAM location RAM_LOW_ADRS. Execution jumps to usrInit().
Compressed VxWorks application images:

q
5-25
Uncompression uses standard routine inate() which is based on the public domain zlib code. For more information on inate()/deate() see:
q
http://www.cdrom.com/pub/infozip/zlib/
Compression of VxWorks object modules typically achieves over 55% compression. Overhead is additional delay of a few seconds at boot time.
Clearing Memory For Cold Boots

For cold boots RAM is re-initialized. Mitigates parity error generation for some hardware (usually activated by read access without initialization). After romStart() relocates ROM image to RAM (but prior to uncompression if necessary) it clears all memory not lled with text and data. Memory is re-initialized to zero a long at a time. Additional memory which is not re-initialized:
q q
Reserved using USR_RESERVED_MEM (cong.h). Reserved using RESERVED (congAll.h). Reserved using STACK_SAVE (congAll.h).
5-26
The macros USR_RESERVED_MEM, RESERVED, and STACK_SAVE will be discussed later in this section. For a warm boot memory is not cleared.
romStart() Stack
Stack pointer for romStart() start initialized to STACK_ADRS by romInit(). romStart() does not return. Its stack is used until kernel is activated. The VxWorks kernel is activated by kernelInit() which spawns a task (with its own stack) to complete system conguration and start user application (usually by spawning another task). Memory for romStart() stack is not re-initialized on cold boot.
Wind River Systems
5-27
Checking Initialization
After nal relocation of image, there may still be problems:
q q
RAM access not working properly. For ROM-resident images data segment may not have been relocated to correct address in RAM. Download environment problems not solved. Code problems.
Verify RAM access by writing to an un-initialized global:

int dummyVar; /* BSS segment variable */ .... dummyVar = 13; if (dummyVar != 13) somethingWrongWithRAM();
Wind River Systems
5-28
If download environment problems have not been solved, re-examine development environment issues discussed earlier. Check for code problems using the rst pre-Tornado debug procedures discussed earlier.
ROM-resident Data Segment

For ROM-resident images verify that the data segment has been correctly initialized after the nal relocation:
static int testVal = 13; /* data segment variable */ .... if (testVal != 13) somethingWrongWithData();
If there are problems and RAM access works, check relocation of data segment to RAM. For ROM-resident images romStart() copies the data segment to an architecture specic RAM address computed as an offset from the end of text in ROM. Check offset, particularly if WRS tools were not used to make ROM-resident image.
5-29
The portion of romStart() which copies the data segment to RAM for ROM-resident images is:
.... #if (CPU_FAMILY == SPARC) copyLongs ((UINT *)(etext + 8), (UINT *) RESIDENT_DATA, #elif ((CPU_FAMILY == MIPS) || (CPU_FAMILY == PPC)) copyLongs ((UINT *)(etext + 0), (UINT *) RESIDENT_DATA, #else copyLongs ((UINT *)(etext + 4), (UINT *) RESIDENT_DATA, #endif ((UINT) edata - (UINT) RESIDENT_DATA) / sizeof (long)); ....
Note the architecture specic offset added to the ROM address etext. (Linker assigns ROM addresses to text and RAM addresses to data). RESIDENT_DATA is dened as RAM_HIGH_ADRS.
Modifying romStart()
During BSP development debug code may need to be placed into bootInit.c. Do not modify ../cong/all/bootInit.c. Make a copy of this le in the BSP directory, and modify the copied le.
To link the copy and not the original le, add the following line to Makele after the macro HEX_FLAGS: BOOTINIT = bootInit.c
Macro BOOTINIT is used to access bootInit.c during VxWorks builds in rules.bsp. Default value for this macro is dened in defs.$(WIND_HOST_TYPE) as ../cong/all/bootInit.c.
5-30
romStart() Conguration Macros

Conguration macros control behavior of romStart(). These macros are dened in cong.h, Makele, congAll.h, and bootInit.c. BSP developers are responsible for the conguration macros in cong.h, <bsp>.h, and Makele. bootInit.c should not be modied. Macros in this le are:
q
BSP (or architecture) dependent. - Controlled from cong.h, Makele, and congAll.h. Image type specic. - Controlled at compile time in rules.bsp. BSP developer does not need to modify. Specic to code in bootInit.c.
5-31
romStart() Conguration Macros continued

romStart() conguration macros dened in cong.h:
q q
LOCAL_MEM_LOCAL_ADRS - Start of RAM. LOCAL_MEM_SIZE - Size of RAM. USER_RESERVED_MEM - Number of reserved bytes. Memory reserved from top of RAM and will not be cleared on cold boot or used by VxWorks. RAM_HIGH_ADRS - RAM load address for non-ROMresident VxWorks boot images. RAM_LOW_ADRS - RAM load address for non-ROMresident VxWorks application images. ROM_TEXT_ADRS - Boot ROM entry address. ROM_SIZE - Size of ROM. ROM_BASE_ADRS - Base address of ROM.
5-32

romStart() conguration macros dened in Makele:
q q
RAM_HIGH_ADRS - Must agree with cong.h RAM_LOW_ADRS - Must agree with cong.h ROM_TEXT_ADRS - Must agree with cong.h ROM_SIZE - Must agree with cong.h RESERVED - Number of reserved bytes. Memory reserved from bottom of RAM, and will not be cleared on cold boot. STACK_SAVE - Maximum stack size for romStart(). Architecture specic. Not cleared on cold reboot.
romStart() conguration macros dened in congAll.h:

q
Wind River Systems
5-33

romStart() conguration macros dened in bootInit.c:
q
USER_RESERVED_MEM - Will be dened as zero if not dened in cong.h. SYS_MEM_BOTTOM - For cold boot, memory will be cleared starting at this address. It expands to: LOCAL_MEM_LOCAL_ADRS + RESERVED. SYS_MEM_TOP - For cold boot, memory will be cleared up to (but not including) this address. It expands to: LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE - USR_RESERVED_MEM. UNCMP_RTN - Name (address) of uncompression routine. ROM_OFFSET - Macro to re-compute absolute addresses which are not PIC compatible.
5-34

q
RAM_DST_ADRS - Final relocation address for compressed image. Default value is RAM_HIGH_ADRS, redened when necessary at compile time in rules.bsp. RESIDENT_DATA - Architecture specic. Dened as RAM_DST_ADRS for MIPS and PowerPC. Dened as the start of the data segment otherwise. ROM_COPY_SIZE - For uncompressed and ROMresident images size of image to relocate. ROM_BASE_ADRS - Dened in cong.h. Redened as romInit if BOOTCODE_IN_RAM is dened. binArrayStart - Start of compressed binary image. binArrayEnd - End of compressed binary image.
5-35
BOOTCODE_IN_RAM is an optional conguration macro discussed in what follows (x86 architecture only).

Optionally dened conguration macros for romStart():
q
BOOTCODE_IN_RAM - Used to not clear RAM on cold boot. If RAM is already initialized this macro allows BSP developer to avoid RAM initialization on cold boot. Must be dened in cong.h (x86 architecture only). UNCOMPRESS - Dened at compile time in rules.bsp for uncompressed image. Does not need to be redened. ROM_RESIDENT - Dened at compile time in rules.bsp for ROM-resident image. Does not need to be redened.
Wind River Systems
5-36
ROM Layout
ROM_BASE_ADRS ROM_SIZE binArrayEnd Compressed Image Segment binArrayStart Uncompressed Image Segment ROM_TEXT_ADRS ROM_BASE_ADRS
5-37
Figure not to scale. The compressed image segment is only relevant for compressed ROM images.
RAM Layout
User reserved zero lled on cold boot Relocated ROM Image STACK_SAVE zero lled on cold boot RESERVED SYS_MEM_BOTTOM LOCAL_MEM_LOCAL_ADRS
sysPhysMemTop() SYS_MEM_TOP
RAM_DST_ADRS
5-38
Figure not to scale. Figure represents RAM state after nal relocation of ROM image. RAM_DST_ADRS will be:
q q
RAM_HIGH_ADRS for VxWorks boot images. RAM_LOW_ADRS for application VxWorks images. Text and data for ROM images. Data for ROM-resident images.
Image segments relocated to RAM_DST_ADRS:

q q
sysPhysMemTop() is function which returns the address of the top of physical memory. The routine is in sysLib.c and its return value is: LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE
romStart() - Some dos and donts

Do not modify code. Functionality is controlled by modifying conguration macros. Code is written in C. Portion which executes in ROM should be PIC and should use a macro to compute PC relative addresses when necessary. Sequence of execution:
q q
Copies appropriate ROM image segments to RAM. Clears portions of RAM not being used (cold boot). Performs uncompression if required. Passes control to generic pre-kernel code (usrInit()).
usrInit() stack begins at nal relocation address and grows away from relocated image.
5-39
romStart() code in Appendix C.

PIC and VxWorks

bootInit.c : romStart()
5.5
sysALib.s : sysInit()
Wind River Systems
5-40
sysInit() Basics
Entry point for loadable VxWorks images. Processor is jumped to sysInit() after image is loaded into RAM. sysInit() resides at the load address for loadable VxWorks images RAM_LOW_ADRS. Performs minimum required setup to execute usrInit(). The remainder of hardware initialization is performed by generic pre-kernel code. Performs all the functions of romInit() except for memory system initialization. Routine is written in assembly language and resides in le sysALib.s.
5-41
For loadable images it is assumed that the memory system has been initialized prior to loading VxWorks. Memory used by the VxWorks boot image is reclaimed by the loaded image and incorporated into the system memory pool later in the initialization sequence of the loaded image.
sysInit() Code
Routine must:
q q
Mask processor interrupts and reset processor. Initialize stack pointer and other registers to begin executing usrInit() and passing the boot type.
Hardware initialization completed in sysHwInit(). Once romInit() code has been written, it will only need to be modied to create sysInit():
q q
Memory initialization code removed. Upon completion jump to usrInit() not romstart(). Code executes in RAM, does not need to be PIC.
Linked into all VxWorks image types but only executed for loadable images.
5-42
sysInit() is linked into all VxWorks images through the macro MACH_DEP which also links code from sysLib.c which is required for all VxWorks image types. The nal link rule for the default (loadable) image is:
$(LD) $(LDFLAGS) -e $(SYS_ENTRY) $(LD_LOW_FLAGS) \ -o vxWorks dataSegPad.o vxWorks.tmp ctdt.o
SYS_ENTRY is dened as _sysInit in defs.bsp. sysALib.s and sysLib.c code is linked into vxWorks.tmp using MACH_DEP.
Stack Initialized by sysInit()

Stack for usrInit() set up by sysInit() grows away from VxWorks image to lower addresses in memory. Must be accounted for when determining load address for VxWorks image.
Memory between RAM_LOW_ADRS and LOCAL_MEM_LOCAL_ADRS contains parameters which should not be over-written by the stack for usrInit() (which never returns). Some of these parameters are target environment specic others are generic:
q q
Exception description message. Shared memory anchor address. Boot line.

5-43
The routine usrInit() does not return. Its stack is used until the kernel is activated.
RAM Layout
sysPhysMemTop()
VxWorks RAM_LOW_ADRS Initial Stack
LOCAL_MEM_LOCAL_ADRS
5-44
Figure not to scale. Figure represents RAM layout after loadable image has been relocated.
Summary
Details of pre-kernel initialization depend on VxWorks image type. VxWorks image type specic code:
q q
romInit() romStart() sysInit()
romInit() and romStart() execute for all images burned into ROM. sysInit() only executes for loadable VxWorks images. Next stage of pre-kernel initialization (following romStart() or sysInit()) is the generic routine usrInit().
5-45

05 preKernelBoot PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 preKernelBoot PDF

Uploaded by

Copyright:

Available Formats

Chapter

Pre-Kernel Initialization - Boot Specic Code

PIC and VxWorks

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

VxWorks Image Types and Generic Code

Wind River Systems

Boot Specic Pre-kernel Initialization Code

romInit() romStart() sysInit()

Wind River Systems

Choice of First Image

Download to RAM - Use vxWorks. Download to ROM - Use vxWorks_rom or vxWorks.res_rom_nosym.

Tornado BSP Training Workshop

Wind River Systems

Pre-Kernel Initialization - Boot Specic Code

PIC and VxWorks

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

Routine is written is assembly language and resides in le romInit.s.

Architecture vs. BSP Specic Issues

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

Cold vs. Warm Boots

Where romInit() begins execution is a function of the boot type:

Stack Pointer Initialization

For non-ROM-resident images the stack will begin:

Tornado BSP Training Workshop

romInit() - Some dos and donts

Tornado BSP Training Workshop

Pre-Kernel Initialization - Boot Specic Code

PIC and VxWorks

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

PIC and VxWorks Builds

Tornado BSP Training Workshop

vxWorks_rom Build Link Flags

LD = ldppc (make.$(CPU)$(TOOL) ) LDFLAGS = -X -N (defs.bsp) LD_PARTIAL_FLAGS = -X -r (defs.bsp)

Wind River Systems

vxWorks_rom Build - ctmp.o

Pre-kernel initialization code in ctmp.o:

romInit() - in romInit.o romStart() - in bootInit_unmcp.o

The nal vxWorks_rom image uses the macro expansions (defs.bsp):

= _romInit = -Ttext $(RAM_LOW_ADRS)

Note, that this nal link also includes:

vxWorks_rom Image and PIC

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

The linker ag RES_LOW_FLAGS expands to:

Text is assigned ROM addresses. Data is assigned RAM addresses.

Pre-Kernel Initialization - Boot Specic Code

PIC and VxWorks 5.4

Tornado BSP Training Workshop

Copyright Wind River Systems

Wind River Systems

Final RAM destination for ROM image segments:

Compressed Image Relocations

Wind River Systems

Compressed Binary Images