NAME

mkproduct - build an image for an ISOS product


Synopsis

mkproduct [options] <product directory> [<hardware type>]


Arguments

The following command line options are provided:

-h
Produce this help text.

-n
Build a flash.bin which is network bootable

-d
Debug build.

-V
report version number

-c dir
'cd' to this directory before starting

-v
be verbose

-D
rebuild dependencies

-C
Clean (delete) build directories

-k
Keep going when some targets can't be made

-W opt
pass 'opt' through to 'aconfig'

b dir
Change build directory

<product directory>
Name of *directory* containing the product .cfg file.

<hardware tpye>
Name of a hardware file


DESCRIPTION

mkproduct will build a flash image for a Virata product. It automates the use of aconfig, make, and mkhfflash; and removes the need for the user to use these tools directly.

mkproduct reads in product definition files. These files are contained within the atmos/products directory. Each product has its own directory within the products directory as multiple configuration files are required for each product. See the CONFIGURATION FILES section for a description of these files.

When mkproduct has completed its execution it will place the flash image(s) in an atmos/build/products/<product name> directory. In the case of a simulator build the executable will be placed in this directory.

mkproduct is able to build a system from a mixture of pre-built object files and/or source files. For example a given product might be using a PP image built from sources but using an NP image which has been distributed in object format. If during its execution mkproduct is required to build a particular system but no system file is available, then it will try to locate pre-built objects for this system. Objects distributed by Virata should be placed in the atmos/products/objects directory.

The first time mkproduct is executed it will execute aconfig for the components it requires. Subsequent instantiations of mkproduct will try to use make before using aconfig so that the build is quicker. For the majority of source code changes mkproduct will successfully rebuild the system. However there are some circumstances, for example if a source file includes a header which wasn't previously in its path, which cause the dependencies of the system to change. In this situation mkproduct should be run once with the '-D' option.

Unlike makebuild, mkproduct does not require a different product file for normal and debug builds. Instead, the same name is used but the '-d' option is specified to select debug builds.

Some systems support simulator builds which can be selected by giving mkproduct a '-s' option. This can also be combined with the '-d' option to have a debug simulator build.

The hardware type option refers to a hardware file in atmos/source/hardware that describes the hardware platform the images is being built for. If no hardware type is specified, mkproduct will use the environment variable VIRATA_HWTYPE if it is set.


CONFIGURATION FILES

mkproduct.cfg contains a description of which system files are needed to build the product. These can be varied depending on the type of build being performed (eg. simulator or debug). It is also possible to override default options within this file; for example, to tell the system to only build the image and not to do the mkflash part.

mkproduct.pst is executed once aconfig or make have finished (and mkflash if specified). Currently it is only used by simulator builds to produce an executable (effectively replacing the job of mkflash).

mkproduct.usr is executed at the very end of a build. It is provided so that users can execute commands at the end of a build. For example, to copy the flash image to a TFTP server.

mkflash.cfg is the file read by mkflash to describe the properties of the resultant flash image. Refer to the mkflash documentation for a complete description of this file.

flashfs is a directory within the product directory in which files can be placed to be included in the flash image. When the image is used to program flash chips the files appear in flashfs (which in turn are copied into ISFS). When the image is booted over TFTP, PCI, or USB, these files appear directly in ISFS.


EXAMPLES

Produce a flash.bin file in the build/products/bd3000-eth-gateway directory:

    mkproduct products/eth-gateway bd3000

Produce an a.out executable for a Helium simulator in the build/products/modem-bd3000 directory.

    mkproduct C<-s> products/modem-bd3000


SEE

the aconfig manpage and the mkhfflash manpage