BSP Flavor

Sometimes, there are boards that are similar enough that a single code baseline can be reused to produce a BSP that supports several boards. Each variant of that shared code baseline is called "flavor".

Steps to transform a regular BSP into one that supports building flavors

• Add a bootstrap file with the following content to the mainline BSP tree:

#!/bin/bash

$(dirname $0)/common/dev-kit-utils/bootstrap-multi-platform-bsp "$@"

• Modify configure.ac as follows:

# This is an autoconf file, see
# common/build-utils/Common-Makefile-HowTo.htm for more info.

# The supportedPlatforms available.  ./bootstrap chooses one.
supportedPlatforms="<SPACE-SEPARATED LIST OF SUPPORTED FLAVORS"
AC_INIT(!PLATFORM_NAME!,<VERSION>)

# See Common-Makefile-HowTo.htm#changing-interface for build interface migration instructions.
commonBuildSystemInterface=6

xPossibleHosts="<ARCHITECTURE>"

# Remove instrumented builds until time to verify
xPossibleHostVariations="release debug"

xReleaseDirectory=deos-products/bsp/!PLATFORM_NAME!

xplatformName="!PLATFORM_NAME!"
xPossibleConfigurations="!PLATFORM_NAME!"

# Define profileConformance to be the name of the single configuration.
AC_SUBST(profileConformance,[${xPossibleConfigurations}])

builtin(include, common/build-utils/deos-rules.ac)  # defines REQUIRED_PROG

AC_OUTPUT

If it is needed to change a variable produced by contants.py e.g. The number of cores, it is needed to include a <FLAVOR-NAME>-contants.py file in the shared folder. The file must specify the variables that will be defined for each flavor and at the end, include constants.py.

This is an example of <FLAVOR-NAME>-contants.py to define bootMaxCores for each flavor. Each flavor must specify the variable and constants.py must not redefine the value for this constant.

#!/usr/bin/env python
import os
from region import *

#------------------------------------------------------------------------------
# The maximum number of cores that Deos boot and the multicore kernel
# will execute on.
#------------------------------------------------------------------------------
bootMaxCores = 1

#------------------------------------------------------------------------------
# Constants shared across BSP components.  See generate_make_constants.py for description.
#------------------------------------------------------------------------------
# Load the extension.
constantsFQ = os.path.join(os.path.dirname(os.path.abspath(__file__)),'constants.py')
exec(compile(open(constantsFQ, "rb").read(), constantsFQ, 'exec'),globals())

if __name__ == '__main__':
  # If we're executed as opposed to imported, run this function.
  sys.exit(region.cli(region=phys, constants=publicConstants, env=globals()))

• It's likely the boot makefile has a rule to run constants.py. This rule needs to be adjusted a little bit to call the platform-specific constants file.

The new rule should look similar to:

$(eval $(call region_constants_mk, constants.mk, $(PLATFORM_NAME)-constants.py , $(region_extra_deps), $(constantsBangvarTargets), $(bootObjects)))
$(eval $(call region_memory_map_xml, memory-map.xml, $(PLATFORM_NAME)-constants.py, $(region_extra_deps)))
MORE_FILES_TO_CLEAN += $(constantsBangvarTargets)

• In the documentation, there are details that must be defined on a platform-specific basis. The BSP UG document number and the platform title are some examples. This can be handled by defining several constants and using the APP_CONFIG variable to decide which constants to use.

PLATFORM_TITLE_ls10x8ardb = LS10X8ARDB
DEOSUGDOCNUM_ls10x8ardb = DEOSDOC591
product.name.lower_ls10x8ardb = ls10x8ardb

PLATFORM_TITLE_vpx3_1708 = VPX3-1708
DEOSUGDOCNUM_vpx3_1708 = DEOSDOC800
product.name.lower_vpx3_1708 = vpx3_1708

After including all the needed flavors, set the common variable to the definitive value:

PLATFORM_TITLE = $(PLATFORM_TITLE_$(APP_CONFIG))
DEOSUGDOCNUM = $(DEOSUGDOCNUM_$(APP_CONFIG))
PRODUCT_NAME_LOWER = $(product.name.lower_$(APP_CONFIG))

Other approach would be to handle the common variable assignation in a set of conditionals:

ifneq ($(APP_CONFIG),)
  ifeq ($(APP_CONFIG),imx8qm)
    PLATFORM_TITLE = IMX8QM
    DEOSUGDOCNUM = DEOSDOC547
    PROCESSOR_CORE = A53
    PROCESSOR_OTHERCORES = (A72 and M4)
  endif
  ifeq ($(APP_CONFIG),imx8qm-aarch64)
    PLATFORM_TITLE = IMX8QM-AARCH64
    DEOSUGDOCNUM = DEOSDOC760
    PROCESSOR_CORE = A53
    PROCESSOR_OTHERCORES = (A72 and M4)
  endif
endif

• Finally, while developing documentation it is possible there is the option to reuse document sections or paragraphs and only change one detail for a specific flavor. This can be achieved by using the conformance specifier.

Inside a paragraph:

This is some example test that applies for both flavors. Some of the BSP features are: image selection and validation, generic timestamps logging to the PSIO and <phrase conformance="Flavor-1">memory test</phrase><phrase conformance="Flavor-2">PCIe disabling</phrase>.

The above will produce that for flavor 1, the paragraph in question reads as:

This is some example test that applies for both flavors. Some of the BSP features are: image selection and validation, generic timestamps logging to the PSIO and memory test.

While for Flavor 2, it reads as:

This is some example test that applies for both flavors. Some of the BSP features are: image selection and validation, generic timestamps logging to the PSIO and PCIe disabling.

The same conformance specifier can be used for titles, sections or images.