NAME

tffsBootImagePut( ) - write to the boot-image region of the flash device

SYNOPSIS

STATUS tffsBootImagePut 
    ( 
    int     driveNo,  /* TFFS drive number              */ 
    int     offset,   /* offset in the flash chip/card  */ 
    char *  filename  /* binary format of the bootimage */ 
    )

DESCRIPTION

This routine writes an input stream to the boot-image region (if any) of a flash memory device. Typically, the input stream contains a boot image, such as the VxWorks boot image, but you are free to use this function to write any data needed. The size of the boot-image region is set by the tffsDevFormat( ) call (or the sysTffsFormat( ) call, a BSP-specific helper function that calls tffsDevFormat( ) internally) that formats the flash device for use with TrueFFS.

If tffsBootImagePut( ) is used to put a VxWorks boot image in flash, you should not use the s-record version of the boot image typically produced by make. Instead, you should take the pre s-record version (usually called bootrom instead of bootrom.hex), and filter out its loader header information using an xxxToBin utility. For example:

elfToBin < bootrom > bootrom.bin

Use the resulting bootrom.bin as input to tffsBootImagePut( ).

The discussion above assumes that you want only to use the flash device to store a VxWorks image that is retrieved from the flash device and then run out of RAM. However, because it is possible to map many flash devices directly into the target's memory, it is also possible run the VxWorks image out of flash memory, although there are some restrictions:

1.

The flash device must be non-NAND.

2.

Only the text segment of the VxWorks image (vxWorks.res_rom) may run out of flash memory. The data segment of the image must reside in standard RAM.

3.

No part of the flash device may be erased while the VxWorks image is running from flash memory.

Because TrueFFS garbage collection triggers an erase, this last restriction means that you cannot run a VxWorks boot image out of a flash device that must also support a writable file system (although a read-only file system is OK).

This last restriction arises from the way in which flash devices are constructed. The current physical construction of flash memory devices does not allow access to the device while an erase is in progress anywhere on the flash device. As a result, if TrueFFS tries to erase a portion of the flash device, the entire device becomes inaccessible to all other users. If that other user happens to be the VxWorks image looking for its next instruction, the VxWorks image crashes.

RETURNS

OK or ERROR

SEE ALSO

tffsConfig