Project

General

Profile

MitySOM-AM57x Wiki » Arm Development »

Yocto for MitySOM-AM57X

U-boot/Kernel/Yocto

Reference: TI Building SDK
Reference crops/poky

The crops/poky:ubuntu-18.04 image is setup with all the packages to build Yocto images and we can also use it to build U-boot and the Kernel.

Setup

  • Download a prebuilt toolchain from ARM and extract it to /home/tools (You can put it wherever you like, you'll just need to update the instructions accordingly)
    $ mkdir -p /home/tools/mitysom-57x/
$ wget https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf.tar.xz -O - | tar -Jxv -C /home/tools/mitysom-57x/
  • Pull crops/poky image and echo test
    docker pull crops/poky:ubuntu-18.04
docker run --rm crops/poky:ubuntu-18.04 echo Test

Usage

If we mount our local directory into the docker container we can enter the docker container and run our builds.
  • cd to your work directory
  • Launch poky image
     $ docker run --rm -it -v $PWD:/work -v /home/tools:/home/tools --tmpfs /opt/poky --env "TOOLCHAIN_PATH_ARMV7=/home/tools/mitysom-57x/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf" crops/poky:ubuntu-18.04 --workdir=/work
pokyuser@e34e187356b3:/workdir$ id
uid=9338(pokyuser) gid=502(pokyuser) groups=502(pokyuser)

    Explanation:
    docker run Run a command in a new container
    --rm Automatically remove the container when it exits
    -it Allows interracting with container over STDIN
    -v $PWD:/work Mounts current directory to /workdir inside container
    -v /home/tools:/home/tools Mount tools directory so we can access downloaded toolchain
    --tmpfs /opt/poky Work around: Overrides the /opt/poky directory that crops/poky installs on their image. This updated the toolchain and python version, which is not compatible with the thud yocto build. So by mounting a empty tmpfs over it, we can go back to using the original packages from ubuntu 18.04
    --env "TOOLCHAIN_PATH_ARMV7=/home/tools/mitysom-57x/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf" Set environment variable needed for processor-sdk Yocto build
    crops/poky:ubuntu-18.04 Selects docker image to run
    --workdir=/work Tells crops poky-entry.py script to create a user pokyuser with a matching user id and group id of the owner of /work

Alternatively, we can run a command directly (echo Test) and the docker container will exit when the command finishes.

 $ docker run --rm -it -v $PWD:/work -v /home/tools:/home/tools --tmpfs /opt/poky --env "TOOLCHAIN_PATH_ARMV7=/home/tools/mitysom-57x/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf" crops/poky:ubuntu-18.04 --workdir=/work echo Test
Test

All of this can be wrapped into a bash script so we don't forget. See sources/meta-mitysom/build/docker-poky.sh

Using your Docker image for Yocto Development

There are many ways to use your Docker image for development depending on your needs. Once you have completed the Docker setup previously described, you can use the Yocto project to build your own kernel, U-Boot, and filesystem.

Critical Link uses TI's Yocto infrastructure to generate the MitySOM-AM57x binaries listed under the Files tab.

These instructions will show you how to create a Yocto build structure interactively. Once you are comfortable with the setup, you can script it using a build server (e.g. Jenkins) for repeatable builds.

First, create a development directory and start your docker image and run a shell:

 $ mkdir devel
 $ cd devel
 $ docker run --rm -it -v $PWD:/work -v /home/tools:/home/tools --tmpfs /opt/poky --env "TOOLCHAIN_PATH_ARMV7=/home/tools/mitysom-57x/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf" crops/poky:ubuntu-18.04 --workdir=/work

This will give you a shell prompt inside the docker image. Go to the /work directory (actually the devel directory outside of the docker image) and run the following commands:

Starting with UID : 9337
user@8ec23474095b:~$ cd /work
user@8ec23474095b:~$ git clone  --single-branch --branch criticallink https://support.criticallink.com/git/oe-layersetup.git
user@8ec23474095b:~$ cd oe-layersetup
user@8ec23474095b:~$ ./oe-layertool-setup.sh -f configs/processor-sdk/processor-sdk-06.03.00.106-cl-external-config.txt

This will download many Yocto repositories, including Critical Link's meta-mitysom.

Now, enter the build directory and configure your local.conf. These additions to the local.conf are optional but recommended. The rm_work option helps reduce disk usage and the archiver options are used to save the source code used for your builds. Finally the source command sets up your build environment.

 
user@8ec23474095b:~$ cd build
user@8ec23474095b:~$ source conf/setenv
user@8ec23474095b:~$ echo 'INHERIT           += "rm_work" '    >> conf/local.conf
user@8ec23474095b:~$ echo 'INHERIT           += "archiver"'    >> conf/local.conf
user@8ec23474095b:~$ echo 'ARCHIVER_MODE[src] = "original"'     >> conf/local.conf

Note: For companies which have strict firewalls, you can add the following to attempt to download git repos over http/https instead of the git protocol

user@8ec23474095b:~$ echo 'PREMIRRORS_append = " \
     git://.*/.* git://HOST/PATH;protocol=https \
     git://.*/.* git://HOST/PATH;protocol=http"'     >> conf/local.conf

At this point, your Yocto build environment is configured and you can bring your build. As a starting point, you could build a filesystem, kernel, and U-Boot compatible with our MitySOM-AM57x Dev Board by running:

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake arago-base-tisdk-image

Note: The arago-base-tisdk-image is a pretty minimal filesystem. It does not include wayland or the PVR gpu drivers. The tisdk-rootfs-image does.

You can also build a full image using:
Note: This is a very large build, on a 8-core build machine with nvme build disks it can take >7 hours and >100GB of diskspace

user@8ec23474095b:~$  MACHINE=mitysom-am57x bitbake tisdk-rootfs-image

Or a custom image using (See more about setting up a custom meta layer below):

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake custom-image

A Note about Yocto Errors

A full Yocto build will stress your CPU, RAM, and disk space. This can sometimes cause errors that are difficult to troubleshoot.

If you get an error in a recipe that you did not modify, and you are certain there is not a RAM or disk space problem, you can usually clear the offending error by building the package independently.

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake arago-base-tisdk-image
... <Various status and output from each recipe> ...
NOTE: recipe vlib-c66x-3_2_1_0-r0: task do_populate_lic: Started
WARNING: vlib-c66x-3_2_1_0-r0 do_populate_lic: Could not copy license file /work/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/vlib-c66x/3_2_1_0-r0/vlib_c66x_3_2_1_0/docs/VLIB_Software_Manifest.html to /work/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/vlib-c66x/3_2_1_0-r0/license-destdir/vlib-c66x/VLIB_Software_Manifest.html: [Errno 2] No such file or directory: '/work/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/vlib-c66x/3_2_1_0-r0/vlib_c66x_3_2_1_0/docs/VLIB_Software_Manifest.html'
ERROR: vlib-c66x-3_2_1_0-r0 do_populate_lic: QA Issue: vlib-c66x: LIC_FILES_CHKSUM points to an invalid file: /work/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/vlib-c66x/3_2_1_0-r0/vlib_c66x_3_2_1_0/docs/VLIB_Software_Manifest.html [license-checksum]
ERROR: vlib-c66x-3_2_1_0-r0 do_populate_lic: Fatal QA errors found, failing task.
ERROR: vlib-c66x-3_2_1_0-r0 do_populate_lic: Function failed: populate_lic_qa_checksum
ERROR: Logfile of failure stored in: /work/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/vlib-c66x/3_2_1_0-r0/temp/log.do_populate_lic.32041
NOTE: recipe vlib-c66x-3_2_1_0-r0: task do_populate_lic: Failed
ERROR: Task (/work/sources/meta-ti/recipes-ti/vlib/vlib-c66x_3.2.1.0.bb:do_populate_lic) failed with exit code '1'

In this case, the build was stopped due to an error in the vlib-c66x-3_2_1_0-r0. The error is complaining that it can't find "VLIB_Software_Manifest.html." Instead of just restarting the build, you can run the following commands to reset the vlib-c66x recipe and build it independently: 
user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake -c clean vlib-c66x
user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake vlib-c66x

If that succeeds, the result will be cached and you can re-run your previous bitbake command (e.g. MACHINE=mitysom-am57x bitbake arago-base-tisdk-image).

Yocto Linux Kernel Build

You can change the configuration of the kernel by running:

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake -c menuconfig virtual/kernel

Then, to build the kernel:

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake virtual/kernel

Note: The crops/poky image does not have the required libncurses-dev to run the kernels menuconfig.

You can create your own Dockerfile, using the crops image as a base, and add the missing packages you want
  • mkdir custom-crops && cd custom-crops
  • vim Dockerfile
    FROM crops/poky:ubuntu-18.04
USER root

RUN apt-get install libncurses5-dev -y

USER usersetup
  • docker build . --tag custom_crops
  • Then replace "crops/poky:ubuntu-18.04" in the docker command with "custom_crops" 
    docker run --rm -it -v $PWD:/work -v /home/tools:/home/tools --tmpfs /opt/poky --env "TOOLCHAIN_PATH_ARMV7=/home/tools/mitysom-57x/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf" custom_crops --workdir=/work
pokyuser@a6dbf190ee68:/work/build$ MACHINE=mitysom-am57x bitbake virtual/kernel -c menuconfig
...
Loading cache: 100% |##############################################################################| Time: 0:00:01
Loaded 4677 entries from dependency cache.

Yocto U-Boot Build

user@8ec23474095b:~$ MACHINE=mitysom-am57x bitbake virtual/bootloader

Custom Yocto layer

A custom meta layer is provided as a starting point and found here: https://support.criticallink.com/gitweb/?p=mitysom-am57x/meta-custom.git;a=summary

meta-custom
├── build.sh
├── conf
│   └── layer.conf
├── README
├── recipes
│   └── images
│       └── custom-image.bb
├── recipes-am57
│   └── mitysom-am57f-fpga
│       ├── mitysom-am57f-fpga
│       │   └── fpga_7a15t.bin
│       └── mitysom-am57f-fpga.bbappend
├── recipes-bsp
│   ├── custom-application
│   │   ├── custom-application
│   │   │   └── mitysom-am57x
│   │   │       ├── custom_application.c
│   │   │       └── custom_application.service
│   │   └── custom-application.bb
│   └── u-boot
│       ├── u-boot-cl-ti
│       │   └── mitysom-am57x
│       │       ├── custom.patch
│       │       └── uEnv.txt
│       └── u-boot-cl-ti_%.bbappend
└── recipes-kernel
    └── linux
        ├── linux-cl-ti
        │   └── mitysom-am57x
        │       ├── am57xx-mitysom-custom.cfg
        │       └── am57xx-mitysom-custom.dts
        └── linux-cl-ti_%.bbappend

The word "custom" can be replaced within all of the files and filenames to be replaced with the project name / custom-layer name.

custom-image.bb

This file is the image recipe for the build. In this file, packages can be added to IMAGE_INSTALL argument to install the packages required for your build.

recipes-bsp/custom-application

This recipe is used for compiling and installing a custom application on the file system. This application will start upon boot up.

recipes-bsp/u-boot

These files append the u-boot recipes to modify the u-boot compilation. You can add a custom.patch file and add custom uEnv commands to fit your needs. The provided uEnv.txt makes sure that the custom device tree is selected to boot with. Make sure to change the name to the custom device tree of your project.

recipes-kernel/linux

These files append the kernel recipes to modify the kernel compilation. You can add a custom device tree and change the kernel CONFIG options to fit your needs.

recipes-am57/mitysom-am57f-fpga

This recipe appends the meta-mitysom fpga installation of Critical Link's default fpga binaries. Updating the fpga binary in this directory with a custom fpga binary named accordingly (E.g. fpga_7a15t.bin) will replace the default binary installed and will be used upon boot up.

Building the custom layer

The custom layer comes with a build script capable of building the yocto filesystem and creating an SD card image. The build script uses docker (crops/poky:ubuntu-18.04). The build can be started with one simple command. This command assumes you are in the meta-custom directory.

docker run --rm -it -v $PWD:/work --tmpfs /opt/poky crops/poky:ubuntu-18.04 --workdir=/work /work/build.sh

Once completed, the SD card image will be in the deploy directory. It can be written to an SD card using bmaptool or dd, however the easiest option is to use balenaEtcher. It will even unzip and verify the md5sum for you.

Go to top
Add picture from clipboard (Maximum size: 1 GB)