/* romStart.c - ROM initialization module *//* Copyright 1989-2001 Wind River Systems, Inc. */#include "copyright_wrs.h"/*modification history--------------------01f,26mar02,sbs  correcting data section relocation for ROM compressed images                 (SPR 73785)01e,29nov01,sbs  Adding dual copy mechanism for copying data sections from                 ROM to RAM using new WRS labels for sdata and edata. 01d,27nov01,tpw  Manually unroll copyLongs and fillLongs.01c,06jul98,jmp  added USER_RESERVED_MEM definition if USER_RESERVED_MEM is                 not defined.01b,20may98,ms   minor cleanup to docs and code.01a,22aug97,ms   derived from 04p of bootInit.c and simplified.*//*DESCRIPTIONThis module provides a generic ROM startup facility.  The target-specificromInit.s module performs the minimal preliminary board initialization andthen jumps to the C routine romStart(). It is assumed that the romInit.smodule has already set the initial stack pointer to STACK_ADRS.This module optionally clears memory to avoid parity errors, initializesthe RAM data area, and then jumps to the routine "relocEntry".This module is a replacement for config/all/bootInit.c.CLEARING MEMORYOne feature of this module is to optionally clear memory to avoid parityerrors.Generally, we clear for the bottom of memory (the BSP's LOCAL_MEM_LOCAL_ADRSmacro), to the top of memory (LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE),but avoiding the stack area. In order to avoid trashing the stack area,the BSP's romInit.s must have set the stack pointer to the macro STACK_ADRS.There are three configuration macros which can be overridden in theBSP's config.h file to change how memory is cleared:ROMSTART_BOOT_CLEAR	undefine to not clear memory when bootingUSER_RESERVED_MEM	area at the top of memory to not clearRESERVED		area at the bottom of memory to not clear.bS 22	RAM    --------------  0x00100000 = LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE    |            |    |------------|		= " - USER_RESERVED_MEM    |            |    |  0 filled  |    |            |    |------------|  0x00001000  = RAM_DATA_ADRS    | initial sp |    |------------|		= RAM_DATA_ADRS - STACK_SAVE    |            |    | 0 filled   |    |            |  exc vectors, bp anchor, exc msg, bootline    |            |    |------------|		= LOCAL_MEM_LOCAL_ADRS + RESERVED    |            |    --------------  0x00000000  = LOCAL_MEM_LOCAL_ADRS.bENote: The STACK_ADRS macro defaults to either RAM_DATA_ADRS, orRAM_DATA_ADRS - STACK_SAVE, depending on if the stack grows upor down for the given processor.Note: The RAM_DATA_ADRS macro is passed to us from the Make system.It represents the address to which the data segment is linkedand defaults to the BSP Makefile's RAM_LOW_ADRS macro. For details onhow to change the addresses to which VxWorks is linked, refer to thedocumentation in h/make/defs.vxWorks.INITIALIZING DATAThe other main feture of this module is to initialize the RAM dataarea.The way this is done depends on the kind of image you are building.There are three ROM image types that are supported by the Makesystem:  ROM_RESIDENT	run from ROM, with only the data segment placed in RAM.  ROM_COPY	copy the main image from ROM to RAM and jump to it.  ROM_COMPRESS	uncompress the main image from ROM to RAM and jump to it.The make system will define one of these macros for you, depending on thename of the target you are building (%.rom_res, %.rom_cpy, or %.rom_cmp).There are separate version of romStart for each of these cases.Let's start with the simplest case; ROM_RESIDENT.ROM_RESIDENT IMAGESWhen the board is powered on, the processor starts executing instructionsfrom ROM. The ROM contains some text (code) and a copy of the datasegment. The pictured below is a typical example:.bS 6	ROM    --------------    |            |    |------------|    |    data    |    |------------|  0xff8xxxxx  = ROM_DATA_ADRS    |    text    |    |            |  0xff800008  = ROM_TEXT_ADRS    --------------  0xff800000  = ROM_BASE_ADRS.bEromStart() copies the data segment from ROM_DATA_ADRS to RAM_DATA_ADRS -the address to which it is really linked.The picture below is an example of RAM addresses on a 1 meg board..bS 22	RAM    --------------  0x00100000 = LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE    |            |    |            |    |------------|		= RAM_DATA_ADRS + data segment size    |            |    |data segment|    |            |    |------------|  0x00001000  = RAM_DATA_ADRS    | initial sp |    |------------|		= RAM_DATA_ADRS - STACK_SAVE    |            |    |            |    --------------  0x00000000  = LOCAL_MEM_LOCAL_ADRS.bEROM_COPY and ROM_COMPRESS IMAGESThese images are slightly more complex than ROM_RESIDENT images.The Make system produces an intermediate image, called %.ram_reloc,which runs from RAM. It then embeds the binary for this subimage withina ROM image. The subimage is located between the global symbols"binArrayStart" and "binArrayEnd". The main difference betweenthe ROM_COPY and the ROM_COMPRESS images is how the subimage isstored.For ROM_COMPRESS, the subimage is compressed to save ROM space.A modified version of the Public Domain \f3zlib\fP library is used touncompress the VxWorks boot ROM executable linked with it.  Compressingobject code typically achieves over 55% compression, permitting muchlarger systems to be burned into ROM.  The only expense is the added fewseconds delay while the first two stages complete.For ROM_COPY, the subimage is not compressed to make thestartup sequence shorter.In both cases, the ROM image initially looks like this, withbinArrayStart and binArrayEnd at the end of the ROM data area.The pictured below is a typical example:.bS 6	ROM    --------------    |            |    |------------|  0xff8xxxxx	= binArrayEnd    |  subImage  |    |------------|  0xff8xxxxx	= binArrayStart    |    data    |    |------------|  0xff8xxxxx  = ROM_DATA_ADRS    |    text    |    |            |  0xff800008  = ROM_TEXT_ADRS    --------------  0xff800000  = ROM_BASE_ADRS.bEFor ROM_COPY images, romStart() copies the subimage from binArrayStart toRAM_DST_ADRSFor ROM_UNCOMPRESS images, romStart() first copies the uncompressioncode's data segment to RAM_DATA_ADRS, and then runs the uncompressionroutine to place the subimage at RAM_DST_ADRS.Both the RAM_DST_ADRS and RAM_DATA_ADRS macros are link addresseddefined by the Make system, which default to the BSP Makefile'sRAM_LOW_ADRS and RAM_HIGH_ADRS respectively.For information on how to change link addresses, refer to the filetarget/h/make/rules.bsp.The picture below is an example of RAM addresses on a 1 meg board."temp data" below refers to the uncompression code's data segment..bS 22        RAM    --------------  0x00100000 = LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE    |            |    |            |    |------------|    | temp data  |    |------------|  0x00090000  = RAM_DATA_ADRS    | initial sp |    |------------|              = RAM_DATA_ADRS - STACK_SAVE    |            |    |            |    |------------|    |            |    |  subimage  |    |            |    |------------|  0x00001000  = RAM_DST_ADRS (for non-resident images)    |            |    |            |    --------------  0x00000000  = LOCAL_MEM_LOCAL_ADRS.bESEE ALSO:inflate(), romInit(), and deflate.AUTHORThe original compression software was written by Jean-loup Gaillyand Mark Adler. See the manual pages of inflate and deflate formore information on their freely available compression software.SUMMARY OF CONFIGURATION MACROSMacro		defined		synopsys-----		-------		--------ROM_BASE_ADRS	config.h	Start of ROMROM_TEXT_ADRS	Makefile	Start of text segment within ROM, typically				a CPU-dependant offset from ROM_BASE_ADRS.ROM_DATA_ADRS	Here		Location in ROM containing a copy of the 				data segment. This must eventually be copied				to the RAM address to which it is linked.RAM_DATA_ADRS	rules.bsp	Location in RAM to which the data segment is				really linked.STACK_ADRS	configAll.h	Initial stack pointer.ROMSTART_BOOT_CLEAR configAll.h	Undefine to not clear memory when bootingUSER_RESERVED_MEM configAll.h	Area at the top of memory to not clearRESERVED	configAll.h	Area at the bottom of memory to not clearLOCAL_MEM_LOCAL_ADRS config.hLOCAL_MEM_SIZE	config.hCHANGES from bootInit.c:Three separate version of romStart to make it readable.One each for ROM_COMPRESS, ROM_RESIDENT, and ROM_COPY images.* The ROM_COPY image copys the main image from binArrayStart to  RAM_DST_ADRS and then jumps to it.  The array binArrayStart and the macro RAM_DST_ADRS are provided by the  Make system.* The ROM_COMPRESS image uncompresses the main image from binArrayStart to  RAM_DST_ADRS and then jumps to it.  Before the uncompression can run, this image needs to initialize the  uncompression code's data segment. It does this by copying data from  ROM_DATA to RAM_DATA_ADRS.  The array binArrayStart and the macros RAM_DST_ADRS and RAM_DATA_ADRS  are provided by the Make system. The macro ROM_DATA is a toolchain  dependant macro, which defaults to the global symbol "etext".* The ROM_RESIDENT image copys its data segment from ROM to RAM. As with  the ROM_COMPRESS image, it does this by copying from ROM_DATA to  RAM_DATA_ADRS.*/#include "vxWorks.h"#include "sysLib.h"#include "config.h"#include "usrConfig.h"/* default uncompression routine for compressed ROM images */#ifndef	UNCMP_RTN#   define	UNCMP_RTN	inflate#endif/* toolchain dependant location of the data segment within ROM */#ifndef	ROM_DATA_ADRS#   define	ROM_DATA_ADRS	(UINT *)(etext)#endif/* MIPS needs to write to uncached memory, others just do normal writes */#ifndef UNCACHED#    define	UNCACHED(adr)	adr#endif/* USER_RESERVED_MEM must be set to 0 if not defined */#ifndef USER_RESERVED_MEM#    define USER_RESERVED_MEM 0#endif/* handy macros */#define ROM_DATA(adrs) ((UINT)adrs + ((UINT)ROM_DATA_ADRS - RAM_DATA_ADRS))#define	SYS_MEM_TOP \	(LOCAL_MEM_LOCAL_ADRS + LOCAL_MEM_SIZE - USER_RESERVED_MEM)#define SYS_MEM_BOTTOM \	(LOCAL_MEM_LOCAL_ADRS + RESERVED)#define BINARRAYEND_ROUNDOFF    (ROUND_DOWN(binArrayEnd, sizeof(long)))