Explaining the Freescale Yocto ecosystem

As we saw, Poky metadata starts with the meta, meta-yocto, and meta-yocto-bsp layers, and it can be expanded by using more layers.

An index of the available OpenEmbedded layers that are compatible with the Yocto project is maintained at http://layers.openembedded.org/.

An embedded product's development usually starts with hardware evaluation using a manufacturer's reference board design. Unless you are working with one of the reference boards already supported by Poky, you will need to extend Poky to support your hardware.

Getting ready

The first thing to do is to select which base hardware your design is going to be based on. We will use a board that is based on a Freescale i.MX6 System on Chip (SoC) as a starting point for our embedded product design.

This recipe gives an overview of the support for Freescale hardware in the Yocto project.

How to do it...

The SoC manufacturer (in this case, Freescale) has a range of reference design boards for purchase, as well as official Yocto-based software releases. Similarly, other manufacturers that use Freescale's SoCs offer reference design boards and their own Yocto-based software releases.

Selecting the appropriate hardware to base your design on is one of the most important design decisions for an embedded product. Depending on your product needs, you will decide to either:

• Use a production-ready board, like a single-board computer (SBC)
• Use a module and build your custom carrier board around it
• Use Freescale's SoC directly and design your own board

Most of the times, a production-ready board will not match the specific requirements of an professional embedded system, and the process of designing a complete carrier board using Freescale's SoC would be too time consuming. So, using an appropriate module that already solves the most technically challenging design aspects is a common choice.

Some of the characteristics that are important to consider are:

• Industrial temperature ranges
• Power management
• Long-term availability
• Precertified wireless and Bluetooth (if applicable)

The Yocto community layers that support Freescale-based boards are called meta-fsl-arm and meta-fsl-arm-extras. The selection of boards that are supported on meta-fsl-arm is limited to Freescale reference designs, which would be the starting point if you are considering designing your own carrier board around Freescale's SoC. Boards from other vendors are maintained on the meta-fsl-arm-extras layer.

There are other embedded manufacturers that use meta-fsl-arm, but they have not integrated their boards in the meta-fsl-arm-extras community layer. These manufacturers will keep their own BSP layers, which depend on meta-fsl-arm, with specific support for their hardware. An example of this is Digi International and its ConnectCore 6 module, which is based on the i.MX6 SoC.

How it works...

To understand Freescale Yocto ecosystem, we need to start with the Freescale community BSP, comprising the meta-fsl-arm layer with support for Freescale reference boards, and its companion, meta-fsl-arm-extra, with support for boards from other vendors, and its differences with the official Freescale Yocto releases that Freescale offers for their reference designs.

There are some key differences between the community and Freescale Yocto releases:

• Freescale releases are developed internally by Freescale without community involvement and are used for BSP validation on Freescale reference boards.
• Freescale releases go through an internal QA and validation test process, and they are maintained by Freescale support.
• Freescale releases for a specific platform reach a maturity point, after which they are no longer worked on. At this point, all the development work has been integrated into the community layer and the platforms are further maintained by the Freescale BSP community.
• Freescale Yocto releases are not Yocto compatible, while the community release is.

Freescale's engineering works very closely with the Freescale BSP community to make sure that all development in their official releases is integrated in the community layer in a reliable and quick manner.

Usually, the best option is to use the Freescale BSP community release but stay with the U-Boot and Linux kernel versions that were released as part of the manufacturer's stable BSP release.

This effectively means that you get the latest updates to the Linux kernel and U-Boot from the manufacturer while simultaneously getting the latest updates to the root filesystem from the community, extending the lifetime of your product, and making sure you are up to date with applications, bug fixes, and security updates.

This takes advantage of the manufacturer's QA process for the system components that are closer to the hardware, and makes it possible to use the manufacturer's support while simultaneously getting user space updates from the community. The Freescale BSP community is also very responsive and active, so problems can usually be worked on with them to benefit all parts.

There's more...

The Freescale BSP community extends Poky with the following layers:

• meta-fsl-arm: This is the community layer that supports Freescale reference designs. It has a dependency on OpenEmbedded-Core. Machines in this layer will be maintained even after Freescale stops active development on them. You can download meta-fsl-arm from its Git repository at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/.

  Development discussions can be followed and contributed to by visiting the development mailing list at https://lists.yoctoproject.org/listinfo/meta-freescale.

  The meta-fsl-arm layer pulls both the Linux kernel and the U-Boot source from Freescale's repositories using the following links:

  • Freescale Linux kernel Git repository: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
  • Freescale U-Boot Git repository: http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/

  Other Linux kernel and U-Boot versions are available, but keeping the manufacturer's supported version is recommended.

  The meta-fsl-arm layer includes Freescale's proprietary binaries to enable some hardware features – most notably its hardware graphics, multimedia, and encryption capabilities. To make use of these capabilities, the end user needs to accept Freescale's End-User License Agreement (EULA), which is included in the meta-fsl-arm layer. To accept the license, the following line needs to be added to the project's conf/local.conf configuration file:

  ACCEPT_FSL_EULA = "1"

• meta-fsl-arm-extra: This layer adds support for other community-maintained boards; for example, the Wandboard. To download the layer's content, you may visit https://github.com/Freescale/meta-fsl-arm-extra/.
• meta-fsl-demos: This layer adds a metadata layer for demonstration target images. To download the layer's content, you may visit https://github.com/Freescale/meta-fsl-demos.

Freescale uses another layer on top of the layers above for their official software releases: meta-fsl-bsp-release.

• meta-fsl-bsp-release: This is a Freescale-maintained layer that is used in the official Freescale software releases. It contains modifications to both meta-fsl-arm and meta-fsl-demos. It is not part of the community release.

See also

• For more information, refer to the FSL community BSP release notes available at http://freescale.github.io/doc/release-notes/1.7/