02.03.2014 Views

BSP Developer's Guide

BSP Developer's Guide

BSP Developer's Guide

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

VxWorks 5.5<br />

<strong>BSP</strong> Developer’s <strong>Guide</strong><br />

romInit( ) plus a small offset (see sysToMonitor( ) in sysLib.c). The romInit( )<br />

routine disables interrupts, puts the boot type (cold/warm) on the stack, clears<br />

caches, and branches to romStart( ) in bootInit.c. The stack is placed to begin<br />

before the text section and grows in the opposite direction. The routine romInit( )<br />

must do as little device setup as possible to start executing C code. Hardware<br />

initialization is the function of the sysHwInit( ) routine in sysLib.c.<br />

bootInit.c: romStart( )<br />

The text and data segments are copied from ROM to RAM in these ways:<br />

■<br />

■<br />

■<br />

If the text segment is not ROM-resident, the text and data segments are copied.<br />

If the text segment is ROM-resident, only the data segment is copied.<br />

Unused memory is cleared to initialize it.<br />

■<br />

If necessary, decompression is done.<br />

Atypically, the i960 invokes sysInit(bootType), which eventually invokes<br />

usrInit(bootType), as on all other architectures.<br />

sysALib.s: sysInit( )<br />

VxWorks calls sysInit( ) in normal rebooting to avoid code redundancy, the i960<br />

calls the routine during ROM initialization as well. The sysInit( ) routine, which<br />

must always be the first routine defined in sysALib.s, invalidates caches if<br />

applicable, initializes the system interrupt tables with default stubs, initializes the<br />

system fault tables with default stubs, and initializes all the processor registers to<br />

known default values. It enables tracing, clears all pending interrupts and finally<br />

invokes usrInit(bootType).<br />

This routine must duplicate the hardware initialization done by romInit( ). If not,<br />

then features set up in the boot ROM code could transfer to the VxWorks image.<br />

This is very undesirable as the configuration and initialization actions of the boot<br />

ROM would have influence over the run-time VxWorks images. It would likely<br />

result in the user rebuilding boot ROMs for configuration changes. It might also<br />

result in the user having to use paired sets of boot ROMs and VxWorks images.<br />

usrConfig.c and bootConfig.c: usrInit( )<br />

The usrInit( ) routine (in usrConfig.c) saves information about the boot type,<br />

handles all the initialization that must be performed before the kernel is actually<br />

started, and then starts the kernel execution. It is the first C code to run in VxWorks.<br />

It is invoked in supervisor mode with all hardware interrupts locked out.<br />

34

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!