Creating a New Component

Create New Subversion Component

Typically, people chose to clone an existing component, strip it of customizations, and add the new code.

Here you can find the steps to create a new component (new_component) as a clone of an existing one (old_component).

1. Create the new product/component in the corresponding Bugzilla. Instructions for this can be found at Bugzilla Administration.

   While still reading the howto, the following list of steps will help identify which instructions are relevant for a new combined BSP:

   1. Log into Bugzilla as administrator.
   2. Click on "Administration", and then on "components" (within description of "Products").
   3. In the list of Products, select "BSP".
   4. At the bottom of the page with the list of existing components, click on "Add a new component to product 'BSP'".
   5. Fill out the fields for the new BSP and click on "Add".
   6. Log out from the administrator Bugzilla account.
2. Create a new PCR against the new product/component, to implement the first version of the component.
3. Use svn copy to create the new_component folder as a clone of the old_component. Example:

   svn copy https://deos.ddci.com/scm/Deos/products/bsp/jacinto7evm https://deos.ddci.com/scm/Deos/products/bsp/qualcomm-rb5 -m "PCR 14751. Clone the jacinto7evm to create the new qualcomm-rb5 bsp."

   Note: This cannot be done if you're cloning from a different repository (scm/svn). Instead, manually copy the files, "svn add" them and set their properties. Make sure to add only the files that are versioned in old_component, i.e. don't clone the contents of the common folder.

4. If you used Tortoise to do the copy (instead of the command line example above), the externals did not get copied and you will need to get the externals. Use svn propget svn:externals common > <temp_file> to get the externals from the old_component's "common" folder and svn propset --file <temp_file> svn:externals common to set them in the new_component's "common" folder.

   Note: If this is a BSP with its components combined, there will only be one common folder. Otherwise there will be one per component (boot, pal, config).

   Note: If tests exist for the old_component then the test folder will also contain a "common" folder.

5. Do a svn commit to the cloned component before making any new changes, in order to keep the origin of the component in the history.

   If you used the commandline copy on the server, then it is committed already but you will need to svn up <component> to get the new BSP.

6. Strip out inappropriate references, but keep the index file to update with the new references.
7. Search through the whole repository for the name of the old_component to replace it by the name of the new_component.
8. In the release-notes.xml be sure to read the whole file for accuracy, but especially note the following:
   • Update the designAssurance correctly (reference BSPs are all E, while most custom BSPs are A. Ask leadership if you aren't sure about your component).
   • Refresh the compatibility table. This should only list components to which the new_component is truly dependent and the earliest version it is compatible with.
   • Remove any caveats or known problems that are not applicable to your component. Add new ones, if they are known.
   • Strip the "Changes from Previous Releases" down to just the following:

     <varlistentry>

     <term><token>&component.version; (&component.revision;)</token></term>

     <listitem>

     <itemizedlist>

     <listitem><para>Initial Release.</para></listitem>

     </itemizedlist>

     </listitem>

     </varlistentry>

   • Be sure to read the context to make sure it still makes sense (for example, the supported manufacturer of the used board will likely change).
9. Update the configure.ac with the following minimum changes:
   • The component name (this does not need to change if it is defined with a bangvar)
   • Version - typically 1.0.0
   • xPossibleHosts - if different architectures will be supported
   • xReleaseDirectory (this may not need to change if it is defined with a bangvar)
10. Add new document numbers to the Document Numbers File for the new_component, if they have not been already added. Each document must have a unique identifier, use the next available DOC number for each document you add.
    • The list of documents needed depends on the DAL of the component. DAL E components likely only need a User Guide, but higher DAL components should reserve the document numbers together including the following:
      • <component_name> User Guide
      • Software Requirements and Design for the <component_name>
      • Software Life Cycle Environment Configuration Index for the <component_name>
      • Software Accomplishment Summary for the <component_name>
      • Software Configuration Index for the <component_name>
    • If you are creating a Custom BSP, you have to create the following document numbers:
      • <BSP_name> BSP User Guide
      • Software Requirements and Design for the <BSP_name> BSP Boot
      • Software Requirements and Design for the <BSP_name> BSP PAL
      • Software Life Cycle Environment Configuration Index for the <BSP_name> BSP
      • Software Accomplishment Summary for the <BSP_name> BSP
      • Software Configuration Index for the <BSP_name> BSP

        Note: If this is a NOT a BSP with its components combined, the last three documents (SLCECI, SAS and SCI) need to be defined for both the Boot and PAL, instead of the BSP.

    • If you are creating a Reference BSP, you only have to create <BSP_name> BSP User Guide document number.
    • For BSPs:
      • In the addEntities.bangvar.ent file, update the entities that hold the BSP's document numbers with the previously created numbers.
      • If you are creating a Custom BSP, the following entities should be defined:
        • document.deosugdocnum
        • document.deosdddbootdocnum
        • document.deosdddpaldocnum
      • All BSPs should define document.deosugdocnum.

Add the new Cygwin package

When the component has reached a point that it is ready to be made available to other DDC-I engineers, you will want to add it to the cygwin installer. These are the steps to make the "new_component" appear in the Cygwin installer.

1. Start by reading Adding a New Component.
2. That should point you to Adding a DDC-I package to the Cygwin installer. I recommend following the "Creating the Cygwin Package Offline (Local Subversion)" option.

Add new BSP to the the tftp-update tool

Add the new target to linux03:/tftpboot/tftp-update-targets.txt.