Note: This project was written in July of 2023 using Yocto Project version 4.2"Mickledore" and Linux kernel 6.1 but should continue to be applicable to newer releases
Table of contents- 1 Describe what LLDP is and why it is important
- 2 Provide a list of acronyms
- 3 Understanding Yocto Project versions and codenames
- 4 Host system requirements
- 5 Specify where to find documentation and how to use it
- 6 Start on our project
- 7 Prepare our Docker container
- 8 Initialize the build
- 9 Build the LLDP image
- 10 Prepare for using Flex-Installer
- 11 Burn a SD card with the image we just built
- 12 To return to this project later
- 13 Extra information
LLDP is the NXP Linux SDK (Software Development Kit) which provides the software to enable the features of Layerscape processors and enable use of Layerscape RDB (Reference Design Boards) and Freeway evaluation hardware. The LLDP user experience is very similar to that of Canonical's Ubuntu AArch64 distribution.
LLDP is an acronym that means Layerscape Linux Distribution PoC. The PoC is an acronym that means Proof of Concept. This means that LLDP is provided as a platform for NXP's customers to use to build their own customized Linux SDK for their own custom hardware. LLDP is sometimes written as Layerscape LDP.
LLDP provides
- Bootloaders based on Das U-Boot
- The NXP Linux Kernel
- Standard Linux distibution userspace applications
- Access to the Ubuntu AArch64 repositories
- NXP firmware components for DPAA1, DPAA2, and PPFE
- Trusted Firmware-A (TF-A)
The history of Layerscape SDK's can help explain LLDP
- Linux SDK for QorIQ Processors - Built using Yocto. The last release was in 2017. Provided a typical Yocto experience and not a full distribution experience. Was replaced by LSDK.
- LSDK (Layerscape Software Development Kit) - Built using FlexBuilder. The final release was in August of 2021. This is the version of Linux SDK that shipped with all Layerscape evaluation kits. Provides a full distribution experience. Was replaced by LLDP.
- Yocto with LSDK Components - Built using Yocto. Was a parallel effort with LSDK but was never tightly coupled to LSDK releases. Provided a typical Yocto experience and not a full distribution experience. Is still actively maintained.
- LLDP (Layerscape Linux Development PoC) - Built using Yocto. The first release was in February of 2023. Uses the recipes for Yocto with LSDK Components and adds additional recipes that enable a full distribution experience.
Note: The following is an abridged list, please rely on LLDPUG Section 2 "Acronyms and abbreviations" for a complete list
APT Advanced Packaging Tool
BSP Board Support Package
DPAA Data-Path Acceleration Architecture
DPDK Data Plane Development Kit
LDP Linux Distribution POC
LF
Linux Factory
LLDP Layerscape Linux Distribution POC
LTS Long Term Support
LSDK Layerscape Software Development Kit
POC Proof Of Concept
RDB Reference Design Board
SDK Software Development Kit
TF-A Trusted Firmware-A
UEFI Unified Extensible Firmware Interface
WIC
OEIC
= OpenEmbedded Image Creator
In order to match up the Yocto Project version number to the codename, please refer to the official Yocto Project release activity page under their wiki.
At the time this article was published, these were the latest Yocto Project versions and codenames
4.4 Scarthgap
4.3 Nanbield
4.2 Mickledore
4.1 Langdale
4.0 Kirkstone
Yocto Project is very specific about supported Linux distributions and the distro version number. If you run Yocto Project tools in an environment that is not in the list of supported distros, you may experience problems.
Refer to the Yocto Project reference manual for system requirements, section 1.3 "Supported Linux Distributions"
As of July 2023, these are the supported distributions and versions
Ubuntu 18.04 (LTS)
Ubuntu 20.04 (LTS)
Ubuntu 22.04 (LTS)
Fedora 36
Fedora 37
AlmaLinux 8.7
AlmaLinux 9.1
Debian GNU/Linux 11.x (Bullseye)
OpenSUSE Leap 15.3
OpenSUSE Leap 15.4
The LLDP User Guide also specifies the host requirements in section 4.1 "Host system requirements". As July 2023, Ubuntu 20.04 LTS
is the only specified system.
A)The LAYERSCAPE-SDK web page
The LAYERSCAPE-SDK web page at NXP should be your first destination to find documentation. At the time this article was written, this web page was located in the following hierarchy: Home / Processors and Microcontrollers / Arm Processors / Layerscape Processors / Layerscape LDP
B)The LLDP User Guide
Under the LAYERSCAPE-SDK documentation tab, you should sort by Newest/Date to find the most recent users guide. At the time this article was written, the latest version was Rev L6.1.1_1.0.0 released on 10 May 2023. You should always check to see if a new document has been released. The user guide is provided in both HTML and PDF formats. Please note that the user guide is released with the first version of a new kernel (major.minor) and may not be updated with each subsequent revision for that kernel
Note: The PDF version includes two embedded PDF documents
- DPAA2UM (DPAA2 User Manual)
- WDNCRL (Write Descriptors for NXP CAAM using RTA Library)
C)The GitHub project meta-nxp-desktop
The meta-nxp-desktop GitHub project is the starting point for building a Linux SDK that enables a full distribution experience. This project supports both NXP Layerscape and NXP i.MX processors. The full name for this project is "NXP Linux Yocto Project BSP for Desktop PoC (Proof of Concept)" which is a complicated way of saying "NXP Linux Distribution". The README.md
contains the basic information needed to build a Linux SDK for both i.MX and Layerscape processors. README.md
is the only file in this project that has any relevance to LLDP. In order to make sure that you are viewing the latest version of the README.md
file, you must make sure that you are looking at the latest release. The GitHub project branches and tags can be confusing. At the time this article was written, the latest branch is lf-6.1.22_2.0.0-mickledore
but the default branch is still lf-5.15.71-2.2.0-kirkstone
, so take this as a warning to always check to make sure you are looking at the latest branch and tag.
D)The GitHub project yocto-sdk
The yocto-sdk GitHub project was originally intended to be used for "Yocto with LSDK Components" but is also used today for building LLDP. This project has branches and tags that make much more sense than the meta-nxp-desktop project. Branches are organized by Yocto Project version codename, and the tags are unnecessary for our work. The README.md
should be ignored because it only describes how to build Yocto with LSDK Components. The only files we care about in this project are the manifest .xml
files. The manifest files that have _distro
in the name are for LLDP, and the manifest files that do not have _distro
in the name are for Yocto with LSDK Components. Here is a better explanation of the files for the mickledore branch.
ls-6.1.22-2.0.0.xml
Builds Yocto with LSDK Componentsls-6.1.22-2.0.0_distro.xml
Builds LLDP
Gather documentation
There are two sources of documentation to follow when building LLDP. It is recommended to keep these documents open while you work through this project.
Decide on your target hardware, LLDP release number, and Yocto Project version codename
For this project, I am targeting the NXP FRWY-LS1046A-AC
Freeway Board which uses the NXP LS1046A processor. I will use the latest NXP LLDP release which at the time I wrote this article is 6.1.22-2.0.0
, and this version dictates the Yocto Project version as Mickledore
. You should decide on your targets now.
Create the project directory and move into it.
Your directory structure will likely be different from mine.
[flint@ZBook] $ DIR=/work/layerscape/ls1046/lldp/mickledore && \
mkdir -pv ${DIR} && cd ${DIR}
7 Prepare our Docker containerWe will use Docker to provide a containerized build environment. If you do not have Docker installed, please follow the instructions provided in this project
We will use a Dockerfile to automate building our Docker image. The Dockerfile name is yocto-mickledore-ubuntu-20
and can be found attached to this project. This file is a text script that instructs Docker how to build an image.
Although the Dockerfile has the word mickledore
in it, there is a very high probability that this Dockerfile will continue to be useful for subsequent Yocto Project releases.
Save the Dockerfile to your download directory ${HOME}/Downloads
Build the Docker image
The command we are going to issue will
- use a Dockerfile called
<DockerFile>
- to build a Docker image named
<ImageName>
- Note: Don't forget the dot "." at the end of the command.
- Note: Don't forget to change the Dockerfile location to where you installed it.
EXAMPLE $ docker build --no-cache \
--file <DockerFile> \
--tag <ImageName> .
I will configure the command as follows, given both the Dockerfile and the resulting image the same name
<DockerFile> = yocto-mickledore-ubuntu-20
<ImageName> = yocto-mickledore-ubuntu-20
Issue this command to build the Docker image
[flint@ZBook] $ docker build --no-cache \
--file "${HOME}/Downloads/yocto-mickledore-ubuntu-20" \
--tag yocto-mickledore-ubuntu-20 .
The process of building the yocto-mickledore-ubuntu-20
Docker image will take at least a few minutes.
Deploy our Docker image to a container while mounting the working directory
Note: The difference between a Docker image and a Docker container is when a Docker image is deployed (run), the specific instance is called a Docker container. We can use the Docker image we just built and deploy it to as many Docker containers we want.
The command we are going to issue will
- use Docker image
<ImageName>
- to create a Docker container called
<ContainerName>
- that will have a computer host name of
<HostName>
and will link the filesystems of
- the Docker container home directory
<ContainerHome>
- to our host computer directory
<HostDirectory>
EXAMPLE $ docker run -dit -P \
--hostname <HostName> \
--name <ContainerName> \
-v <HostDirectory>:<ContainerHome> \
<ImageName>
I have configured my command as follows
<ImageName> = yocto-mickedore-ubuntu-20
<ContainerName> = ls1046-lldp-mickledore
<HostName> = Docker
<ContainerHome> = /work/layerscape/ls1046/lldp/mickledore
<HostDirectory> = /home/build
Issue this command to deploy the Docker image to a container
[flint@ZBook] $ docker run -dit -P \
--hostname Docker \
--name ls1046-lldp-mickledore \
-v /work/layerscape/ls1046/lldp/mickledore:/home/build \
yocto-mickedore-ubuntu-20
Attach (Log In) to the new container
[flint@ZBook] $ docker attach ls1046-lldp-mickledore
Install dotfiles (optional)
I prefer my Docker containers to operate similarly to my host computer's Linux Bash shell, so I install my personal dotfiles to give me that environment. This is purely optional for you. My dotfiles are attached to this project in a zip archive for you to review.
When I install my dotfiles into a Docker container, I use the following command
[build@Docker] $ curl https://gitlab.com/fweller/flint-configuration/-/raw/master/Tools/dockerfiles/dotfiles/dockerfile-install-dotfiles.sh?ref_type=heads | bash && source .bashrc
At this point our Docker container is ready for use
8 Initialize the buildNXP uses Repo to create an environment for building LLDP. Google Repo is "the multiple Git repository tool". The Dockerfile already installed Repo for us and placed it in location /usr/local/bin/repo
Install Repo (for reference only)
Note: This is for reference, the way you would install Repo as per NXP documentation. Only follow this if you did not use the supplied Dockerfile is as per the NXP instructions
EXAMPLE $ mkdir ~/bin && \
curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo && \
chmod a+x ~/bin/repo && \
PATH=${PATH}:~/bin
Initialize Repo
The command we are going to issue will
- use URL
<URL>
to retrieve a manifest repository - using manifest file
<ManifestFile>
within the repository - and the specific manifest-branch
<Branch>
EXAMPLE $ repo init \
-u <URL> \
-b <Branch> \
-m <ManifestFile>
The specifics for our build are as follows. You should expect to update these values based on newer branches and manifest files.
<URL> https://github.com/nxp-qoriq/yocto-sdk.git
<ManifestFile> ls-6.1.22-2.0.0_distro.xml
<Branch> mickledore
This is the command that I issued. You should now build your own command and issue it.
[build@Docker] $ repo init \
-u https://github.com/nxp-qoriq/yocto-sdk.git \
-b mickledore \
-m ls-6.1.22-2.0.0_distro.xml
Download the NXP Yocto layers
Instructing Repo to sync is basically telling it to download files
[build@Docker] $ repo sync
When Repo is done initializing (downloading) everything, you should see 3 files and one directory
[build@Docker] $ ls -l
lrwxrwxrwx 1 build build 40 Jul 28 14:33 distro-setup-env -> sources/meta-nxp-desktop/tools/setup-env
lrwxrwxrwx 1 build build 34 Jul 28 14:33 README-DISTRO -> sources/meta-nxp-desktop/README.md
-r--r--r-- 1 build build 13K Jul 28 14:33 setup-env
drwxr-xr-x 15 build build 4.0K Jul 28 14:33 sources
Specify the target hardware
The instruction we are going to run will set up the environment for the specified <Machine>
EXAMPLE $ source distro-setup-env -m <Machine>
The supported boards as of the time this article was published are as follows:
- ls1012ardb
- ls1012afrwy
- ls1021atwr
- ls1043ardb
- ls1046ardb
- ls1046afrwy
- ls1088ardb-pb
- ls1028ardb
- ls2088ardb
- lx2160ardb-rev2
- lx2162aqds
The target I will build for is the LS1046 Freeway board, but please make your selection as per your board. Replace the "ls1046afrwy" in the following command with the name of the board in the above list that matches your hardware.
[build@Docker] $ source distro-setup-env -m ls1046afrwy
You will then be asked to confirm overwriting 'conf/bblayers.conf~
' about 16 times. Just type in Y + <Return>
for each one.
Next you will be asked to scroll through a license agreement with <Space>
and then accept it: Y + <Return>
When finished, your working directory will change. Mine is now /home/build/build_ls1046afrwy
Make note of the text provided after the license agreement as it will instruct you how to configure the build environment should you wish to return at a later time.
For me, the command would be
$ . /home/build/build_ls1046afrwy/SOURCE_THIS
Note: The dot "." in the above command is equivalent to the "source" command.
9 Build the LLDP imageThere are three Bitbake configurations that can be run
ls-image-lite This is a minimal configuration
ls-image-main This is the standard configuration
ls-image-desktop This is for the LS1028 only as it includes a desktop GUI
The configuration ls-image-main
is most likely what you want to use.
I prefer to instruct Bitbake to download all of the required files before I instruct it to begin the build. This way I can catch download issues in a few minutes instead of waiting hours for the build process to fail.
Fetch (download) all the packages
[build@Docker] $ bitbake ls-image-main --runall fetch
Bitbake will issue some warnings while is parses recipes. After all the recipes are parsed, Bitbake will begin fetching packages. For my particular build, this requires 363 tasks which takes at least 5 minutes to complete.
Now that Bitbake has completed fetching all the packages, it is time to kick off the build process. Just issue the same command as before but without the "--runall fetch
"
Build all the packages
[build@Docker] $ bitbake ls-image-main
The build process will take at least a few hours
Build Completion
All the output files that we care about have been placed into the deployed machine image folder that will be in a location with this configuration
build_<Machine>/tmp/deploy/images/<Machine>
For the example I have been using, where <Machine> = ls1046afrwy, the exact folder location is:
- Within the Docker image:
/home/build/build_ls1046afrwy/tmp/deploy/images/ls1046afrwy
- On the host computer:
/work/layerscape/ls1046/lldp/mickledore/build_ls1046afrwy/tmp/deploy/images/ls1046afrwy
Change directory to the image deploy folder and list the Wic files
[build@Docker] $ cd /home/build/build_ls1046afrwy/tmp/deploy/images/ls1046afrwy
[build@Docker] $ ls -l *wic*
There are 4 results
-rw-r--r-- 2 build build 5.3K Jul 28 18:05 ls-image-main-ls1046afrwy-20230728222204.rootfs.wic.bmap
-rw-r--r-- 2 build build 692M Jul 28 18:04 ls-image-main-ls1046afrwy-20230728222204.rootfs.wic.bz2
lrwxrwxrwx 2 build build 56 Jul 28 18:05 ls-image-main-ls1046afrwy.wic.bmap -> ls-image-main-ls1046afrwy-20230728222204.rootfs.wic.bmap
lrwxrwxrwx 2 build build 55 Jul 28 18:05 ls-image-main-ls1046afrwy.wic.bz2 -> ls-image-main-ls1046afrwy-20230728222204.rootfs.wic.bz2
The important filename is ls-image-main-ls1046afrwy.wic.bz2
which is a symbolic link to the actual file, which includes a date and time stamp in the name. For my project this is called ls-image-main-ls1046afrwy-20230728222204.rootfs.wic.bz2
The significant thing about the Wic file is that this can be burned to a SD card, which can in turn be inserted into the Layerscape evaluation kit. While this is very useful for initial testing of the evaluation kit, we eventually want to program the flash on the kit or on our custom board.
Yocto Project has some documentation on how to use Wic files
10 Prepare for using Flex-InstallerWe use Flex-Installer to burn the BSP to embedded flash devices on the evaluation kits or custom hardware. Flex-Installer expects more files than what was generated with our previous bitbake command. We will generate two more sets of files
- Composite firmware
- Tarball
Note: Output files for the next two commands will be placed into the same folder as the previous bitbake command
The composite firmware consists of RCW/PBL, ATF, Bootloader (U-Boot or UEFI), secure headers, Ethernet MAC/PHY firmware, dtb, kernel and tiny initrd RFS. The composite firmware can be programmed at offset 0x0 in flash device or at offset block# 8 in a SD/eMMC card.
Generate the composite firmware
[build@Docker] $ bitbake qoriq-composite-firmware
The build takes a few minutes
Many files are generated. Some of the more important files are named firmware_<Machine>_uboot_<FlashDevice>.img
On my project I can see two .img
files
firmware_ls1046afrwy_uboot_qspiboot.img
firmware_ls1046afrwy_uboot_sdboot.img
In the tarball, the boot image puts dtb, image, secure-boot header, and the kernel module. boottgz writes in boot part2.
Generate the Tarball
[build@Docker] $ bitbake generate-boottgz
The process completes in less than one minute
The important output file is named boot_<Machine>_lts_6.1.tgz
so as an example, for my project it is called boot_ls1046afrwy_lts_6.1.tgz
To exit the Docker container
Type
[build@Docker] $ exit
And immediately I am presented with my host terminal again
[flint@ZBook] $
11 Burn a SD card with the image we just builtThe first Bitbake command created a compressed wic file which is the only file we need to program a SD card
On the host computer we need to change directory to the deployed machine image directory
build_<Machine>/tmp/deploy/images/<Machine>
For the example in this training, this is the directory: /work/layerscape/ls1046/lldp/mickledore/build_ls1046afrwy/tmp/deploy/images/ls1046afrwy
Change to the deployed machine image folder
[flint@ZBook] $ cd /work/layerscape/ls1046/lldp/mickledore/build_ls1046afrwy/tmp/deploy/images/ls1046afrwy
Decompress the bzip2 file
Two methods to decompress a bz2 file are provided below, please only use one method.
Decompress the bzip2 file using bunzip2 (option 1)
bunzip2 is the traditional application to decompress a bzip2 file, and is usually pre-installed on many Linux Distributions. bunzip2 operates with only a single thread, which does not make good use of a multi-core host computer. A better tool to use is lbzip2 which is multi-threaded and will run on every core of the host machine.
[flint@ZBook] $ bunzip2 -dk -f ls-image-main-ls1046afrwy.wic.bz2
Decompress the bzip2 file using lbunzip2 (option 2)
lbunzip2 uses the same flags as bunzip2 but supports multi-threaded operation, so the decompression completes significantly faster than when using bunzip2.
[flint@ZBook] $ sudo apt install lbzip2
[flint@ZBook] $ lbunzip2 -dk -f ls-image-main-ls1046afrwy.wic.bz2
The decompressed file will have the same name but without the .bz2
at the end
There are many tools to burn a Wic image to a SD card. Balena Etcher is one such popular tool. My preferred method is to use the dd "disk duplicator" tool. But beware, dd is also known as "disk destroyer" if you end up writing to an unintended device.
Burn the Wic image to an SD card
In the example below
<ImageName>
is the filename for the.wic
file<Device>
is the disk device name such as/dev/sda
NOTE: Be certain that you know the exact /dev/sdx for the sd card or else you risk overwriting an important filesystem
EXAMPLE: $ sudo dd if=<ImageName> of=<Device> bs=4k conv=fsync status=progress && sync
For my setup, the command will be
[flint@ZBook] $ sudo dd if=ls-image-main-ls1046afrwy.wic of=/dev/sdb bs=4k conv=fsync status=progress && sync
12 To return to this project laterThe following are the steps needed to restart a stopped container and attach to it
List all Docker containers, including stopped containers
[flint@ZBook] $ docker container ls -a
I can see the Docker container that I named ls1046-lldp-mickledore
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f49852663ff7 yocto-mickedore-ubuntu-20 "/bin/bash" 3 days ago Exited (0) 2 days ago ls1046-lldp-mickledore
Restart the Docker container
[flint@ZBook] $ docker restart ls1046-lldp-mickledore
List all Docker containers that are presently running
[flint@ZBook] $ docker container ls
I can see that my container is running
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f49852663ff7 yocto-mickedore-ubuntu-20 "/bin/bash" 3 days ago Up 8 seconds ls1046-lldp-mickledore
Attach to the Docker container
[flint@ZBook] $ docker attach ls1046-lldp-mickledore
I am immediately presented with a prompt from my container
[build@Docker] $
In order to make sure that the terminal we are running has the right configuration for kicking off another build, we must source the SOURCE_THIS
file
[build@Docker] $ source /home/build/build_ls1046afrwy/SOURCE_THIS
Now we can continue with performing another build
13 Extra informationUnderstanding the meta-nxp-desktop branch naming convention
Example: lf-6.1.22_2.0.0-mickledore
- Linux Factory kernel 6.1.22
- Version 2.0.0
- Yocto Project version 4.2 "Mickledore"
The branch starting text is very important
- Starting with "lf-" are for Layerscape processors
- Starting with "imx-" are for i.mx processors
Understanding the meta-nxp-desktop tag naming convention
Example: rel_lf_6.1.22_2.0.0_ldp
- Linux Factory (Layerscape) kernel 6.1.22
- Version 2.0.0
- For LLDP
Note: The tag start and end text is very important
- Starting with "rel_lf" and ending with "_ldp" are for Layerscape processors
- Starting with "rel_lf" and ending with "_desktop" are for Layerscape LS1028 only
- Starting with "rel_imx" and ending with "_desktop" are for i.MX processors
Comments
Please log in or sign up to comment.