On this page:
Building NXP/Embedian’s Yocto Rocko BSP Distribution
Eric Lee
version 1.0a, 1/16/2019
Introduction
This document describes how Embedian builds a customized version of NXP’s i.MX7 official Yocto Rocko BSP release for Embedian's SMARC-FiMX7 product platform. The approach is to pull from Embedian's public facing GIT repository and build that using bitbake. The reason why we use this approach is that it allows co-development. The build output is comprised of binary images, feed packages, and an SDK for SMARC-FiMX7 specific development.
Freescale makes their i.MX series official bsp build scripts available via the following GIT repository:
It is this repository that actually pulls in the fsl-bsp-release project to perform the Linux BSP builds for Freescale's i.MX7 ARM Cortext-A7 chips.
Generating SSH Keys
We recommend you use SSH keys to establish a secure connection between your computer and Embedian Gitlab server. The steps below will walk you through generating an SSH key and then adding the public key to our Gitlab account.
Step 1. Check for SSH keys
First, we need to check for existing ssh keys on your computer. Open up Git Bash and run:
Check the directory listing to see if you have a file named either id_rsa.pub
or id_dsa.pub
. If you don't have either of those files go to step 2. Otherwise, you already have an existing keypair, and you can skip to step 3.
Step 2. Generate a new SSH key
To generate a new SSH key, enter the code below. We want the default settings so when asked to enter a file in which to save the key, just press enter.
Now you need to enter a passphrase.
Which should give you something like this:
Step 3. Add your SSH key to Embedian Gitlab Server
Copy the key to your clipboard.
Go to Embedian Git Server. At Profile Setting --> SSH Keys --> Add SSH Key
Paste your public key and press "Add Key" and your are done.
Overview of the meta-smarcfimx7-rocko Yocto Layer
The supplied meta-smarcfimx7 Yocto compliant layer has the following organization:
Notes on meta-smarcfimx6-rocko layer content
conf/machine/*
This folder contains the machine definitions for the imx7dsmarc|imx7ssmarc|imx72dsmarc platform and backup repository in Embedian. These select the associated kernel, kernel config, u-boot, u-boot config, and tar.bz2 image settings.
recipes-bsp/u-boot/*
This folder contains recipes used to build DAS U-boot for imx7dsmarc|imx7ssmarc|imx72dsmarc platform.
recipes-core/busybox/*
This folder remove telnetd from bysybox for imx7dsmarc|imx7ssmarc|imx72dsmarc platform.
recipes-connectivity/connman/*
This folder unmask connman service for imx7dsmarc|imx7ssmarc|imx72dsmarc platform to make networking work.
recipes-kernel/linux/*
Contains the recipes needed to build the imx7dsmarc|imx7ssmarc|imx72dsmarc Linux kernels.
Setting Up the Tools and Build Environment
To build the latest Freescale i.MX7 fsl-bsp-release, you first need an Ubuntu 16.04 LTS installation. Since bitbake does not accept building images using root privileges, please do not login as a root user when performing the instructions in this section.
Once you have Ubuntu 16.04 LTS running, install the additional required support packages using the following console command:
If you are using a 64-bit Linux, then you'd also need to install 32-bit support libraries, needed by the pre-built Linaro toolchain and other binary tools.
You’ll also need to change the default shell to bash from Ubuntu’s default dash shell (select the <No> option):
To get the BSP you need to have 'repo' installed and use it as:
Install the 'repo' utility:
This script will create and bring you to ~/smarc-fimx7-rocko-release/imx7d-qt5fb directory.
To build Embedian/Freescale Yocto BSP, use the following commands:
Once it done, you can find all required images under ~/smarc-fimx7-bsp-release/<build directory>/tmp/deploy/images/<machine name>/
You may want to build programs that aren’t installed into a root file system so you can make them available via a feed site (described below.) To do this you can build the package directly and then build the package named package-index to add the new package to the feed site.
The following example builds the minicom program and makes it available on the feed site:
~/smarc-fimx7-bsp-release/<build directory>/tmp/deploy
.deploy/images/<machine name>/*
This folder contains the binary images for the root file system and the Embedian SMARC-FiMX7 specific version of the u-boot, zImage and device tree file. Specifically the images are:
deploy/images/<machine name>/u-boot.imx
This u-boot bootloader binary for SMARC-FiMX7
deploy/images/<machine name>/zImage
The kernel zImage for SMARC-FiMX7.
deploy/images/<machine name>/imx7d-smarcfimx7.dtb
The device tree binary file for SMARC-FiMX7 Dual core.
deploy/images/<machine name>/imx7s-smarcfimx7.dtb
The device tree binary file for SMARC-FiMX7 Solo core.
deploy/images/<machine name>/fsl-image-validation-imx-<machine name>.*
Embedian root file system images for software development on Embedian’s SMARC-FiMX7 platforms without QT5.
deploy/images/<machine name>/fsl-image-qt5-validation-imx-<machine name>.*
Embedian root file system images for software development on Embedian’s SMARC-FiMX7 with QT5.
deploy/rpm/*
This folder contains all the packages used to construct the root file system images. They are in rpm format (similar format to Fedora packages) and can be dynamically installed on the target platform via a properly constructed feed file. Here is an example of the feed file (named imx7d_qt5fb_update.repo) that is used internally at Embedian to install upgrades onto a imx7dsmarc QT5 platform directly on framebuffer without reflashing the file system:
deploy/licenses/*
Setup SD Card
For these instruction, we are assuming: DISK=/dev/mmcblk0, "lsblk" is very useful for determining the device id.
Erase SD card:
Create Partitions:
Format Partitions:
Mount Partitions:
On some systems, these partitions may be auto-mounted...
Install Bootloader
If SPI NOR Flash is not empty
The u-boot.imx is pre-installed in SPI NOR flash at factory default. SMARC-FiMX7 is designed to always boot up from SPI NOR flash and to load zImage, device tree blob and root file systems based on the setting of BOOT_SEL. If users need to fuse their own u-boot or perform u-boot upgrade. This section will instruct you how to do that.
Copy u-boot.imx to the first boot partition of your SD card.
Fuse u-boot.imx to the SPI NOR flash.
Stop at U-Boot command prompt (Press any key when booting up). Copy and Paste the following script under u-boot command prompt.
If SPI NOR Flash is empty
In some cases, when SPI NOR flash is erased or the u-boot is under development, we need a way to boot from SD card first. Users need to shunt cross the TEST# pin to ground. In this way, SMARC-FiMX7 will always boot up from SD card.
Copy u-boot.imx to the SD card
uEnv.txt based bootscript
Create "uEnv.txt" boot script: ($ vim uEnv.txt)
Copy uEnv.txt to the boot partition:
Install Kernel zImage
Copy zImage to the boot partition:
Install Kernel Device Tree Binary
Install Root File System
Copy Root File System:
Yocto Built Rootfs:
Remove SD card:
Feed Packages
The following procedure can be used on a Embedian SMARC-FiMX7 device to download and utilize the feed file show above to install the tcpdump Ethernet packet analyzer program:
Writing Bitbake Recipes
In order to package your application and include it in the root filesystem image, you must write a BitBake recipe for it.
When starting from scratch, it is easiest to learn by example from existing recipes.
Example HelloWorld recipe using autotools
For software that uses autotools (./configure; make; make install), writing recipes can be very simple:
DESCRIPTION = "Hello World Recipe using autotools" HOMEPAGE = "http://www.embedian.com/" SECTION = "console/utils" PRIORITY = "optional" LICENSE = "GPL" PR = "r0" S = "${WORKDIR}/git" inherit autotools |
SRC_URI
specifies the location to download the source from. It can take the form of any standard URL using http://, ftp://, etc. It can also fetch from SCM systems, such as git in the example above.
PR
is the package revision variable. Any time a recipe is updated that should require the package to be rebuilt, this variable should be incremented.
inherit autotools
brings in support for the package to be built using autotools, and thus no other instructions on how to compile and install the software are needed unless something needs to be customized.
S
is the source directory variable. This specifies where the source code will exist after it is fetched from SRC_URI and unpacked. The default value is ${WORKDIR}/${PN}-${PV}
, where PN
is the package name and PV
is the package version. Both PN
and PV
are set by default using the filename of the recipe, where the filename has the format PN_PV.bb
.
Example HelloWorld recipe using a single source file
This example shows a simple case of building a helloworld.c file directly using the default compiler (gcc). Since it isn’t using autotools or make, we have to tell BitBake how to build it explicitly.
DESCRIPTION = "HelloWorld" SECTION = "examples" LICENSE = "GPL" SRC_URI = "file://helloworld.c" S = "${WORKDIR}" do_compile() { ${CC} ${CFLAGS} ${LDFLAGS} helloworld.c -o helloworld } do_install() { install -d ${D}${bindir} install -m 0755 helloworld ${D}${bindir} } |
In this case, SRC_URI
specifies a file that must exist locally with the recipe. Since there is no code to download and unpack, we set S
to WORKDIR
since that is where helloworld.c will be copied to before it is built.
WORKDIR
is located at ${OETREE}/<build directory>/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/<package name and version>
for most packages. If the package is machine-specific (rather than generic for the cortexa7hf architecture), it may be located in the imx7dsmarc-poky-linux-gnueabi subdirectory depending on your hardware (this applies to kernel packages, images, etc).
do_compile
defines how to compile the source. In this case, we just call gcc directly. If it isn’t defined, do_compile
runs make
in the source directory by default.
do_install
defines how to install the application. This example runs install
to create a bin directory where the application will be copied to and then copies the application there with permissions set to 755.
D
is the destination directory where the application is installed to before it is packaged.
${bindir}
is the directory where most binary applications are installed, typically /usr/bin
.
For a more in-depth explanation of BitBake recipes, syntax, and variables, see the Recipe Chapter of the OpenEmbedded User Manual.
Setup eMMC
Setting up eMMC usually is the last step at development stage after the development work is done at your SD card or NFS environments. From software point of view, eMMC is nothing but a non-removable SD card on board. For SMARC-FiMX7, the SD card is always emulated as /dev/mmcblk0 and on-module eMMC is always emulated as /dev/mmcblk2. Setting up eMMC now is nothing but changing the device descriptor.
This section gives a step-by-step procedure to setup eMMC flash. Users can write a shell script your own at production to simplify the steps.
First, we need to backup the final firmware from your SD card or NFS.
Prepare for eMMC binaries from SD card (or NFS):
Insert SD card into your Linux PC. For these instructions, we are assuming: DISK=/dev/mmcblk0, "lsblk" is very useful for determining the device id.
For these instruction, we are assuming: DISK=/dev/mmcblk0, "lsblk" is very useful for determining the device id.
Mount Partitions:
On some systems, these partitions may be auto-mounted...
Copy zImage to rootfs partition:
Copy uEnv.txt to rootfs partition:
Copy and paste the following contents to /media/rootfs/home/root ($ sudo vim /media/rootfs/home/root/uEnv.txt)
Copy device tree blob to rootfs partition:
Copy real rootfs to rootfs partition:
Remove SD card:
Copy Binaries to eMMC from SD card:
Insert this SD card into your SMARC-FiMX7 device.
Now it will be almost the same as you did when setup your SD card, but the eMMC device descriptor is /dev/mmcblk2 now.
Erase SD card:
Create Partition Layout:
Format Partitions:
Mount Partitions:
Install binaries for partition 1
Copy uEnv.txt/zImage/*.dtb to the boot partition
Install Kernel Device Tree Binary
Install Root File System
Unmount eMMC:
Switch your Boot Select to eMMC and you will be able to boot up from eMMC now.
version 1.0a, 1/16/2019
Last updated 2019-01-16
4 Comments
Johann CAHIER
I'm trying to leverage the M4 core of the imx7.
I tried using a custom Zephyr build, AND with the binary found in the tmp/deploy/image of yocto.
It seems that : if I boot ANY binary on the M4 core, Linux wont boot.
If the M4 core is idle, the SAME linux image boots OK.
Did you test those M4 binaries ? Were you able to boot both cores ?
Thanks in advance for your answer,
Johann CAHIER
Eric Lee
Have you seen this document https://community.nxp.com/docs/DOC-333803?
-Eric
Johann CAHIER
Hello Eric,
Thanks for the link.
Indeed, I didn't came across this document so far.
It contains valuable information.
Please note I managed to get the same use case running on a different iMX7 board (namely the WaRP7), but using a different yocto version, and probably few specific meta layers.
I suspect the problem I'm facing on the embedian SMARC to be related to the DTB deployed by yocto.
I tried some obvious hotfix : that is, disabling (in the linux DTB) any peripheral that I know to be used by the M4 core, specially the dedicated UART, but with no success.
I tried to make a diff of the (decompiled) DTBs (SMARC vs WaRP7) but the node organisation is too different to lead to any exploitable output
I also tried that "uart_from_osc" kernel command line parameter I found out thanks to your link, but sadly with no success (I check in the kernel code, and this parameterit doesn't seem relevant for iMX7 SoCs, only for imx6. Plus the problem it fixes isn't the same I'm facing : "baud rate mess up on M4 side" versus "kernel boot freeze on A7").
My question was about if you (or someone) has already run such a scenario, with success ?
And, if so, I would be VERY interested into the DTB used to run the test !!
NOTE : I activated the early boot printk option to get boot traces before the serial UART is initialized by the kernel.
It seems the point it freeze is when it "normally" initialize the serial UART !
On a normal boot process, I have the following log:
console [ttymxc2] enabled
console [ttymxc2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
imx sema4 driver is registered.
And the boot process goes on.
But when the M4 core is running (using ttymxc1 as serial console), the EARLY_PRINTK traces are the same to this point where I wait the traces above forever...
Thanks in advance,
Johann CAHIER.
Johann CAHIER
NOTE : In the traces I copy/pasted, earlycon0 that correspond to EARLY_PRINTK option, and ttymcx2 that is the classical serial console.
This is the moment at which the kernel swap for the former to the latter.
I guess the enabled / disabled lines are duplicated, because at this moment, the kernel dumps on both UARTs, but they turn out to be the same physical line.