mkproduct - build an image for an ISOS product
mkproduct [options] <product directory> [<hardware type>]
The following command line options are provided:
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.
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.
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