Yocto for embedded

• https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html
• https://www.yoctoproject.org/docs/3.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
• https://medium.com/@shantanoodesai/run-docker-on-a-raspberry-pi-4-with-yocto-project-551d6b615c0b
• https://jumpnowtek.com/rpi/Raspberry-Pi-4-64bit-Systems-with-Yocto.html

The examples in this paper assume you are using a native Linux system running a recent Ubuntu Linux distribution. If the machine you want to use Yocto Project on to build an image (build host) is not a native Linux system, you can still perform these steps by using CROss PlatformS (CROPS) and setting up a Poky container. See the Setting Up to Use CROss PlatformS (CROPS http://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#setting-up-to-use-crops)“ section in the Yocto Project Development Tasks Manual for more information.

 sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
 build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
 xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \
 pylint3 xterm zstd
 

Create build dir

 mkdir -p yocto/rpi4/edgegw/layers
 cd yocto/rpi4/edgegw/layers
 

Among other things, the Yocto Project uses a build host based on the OpenEmbedded (OE) project, which uses the BitBake tool, to construct complete Linux images. The BitBake and OE components are combined together to form a reference build host, historically known as Poky.

Checkout poky

 git clone git://git.yoctoproject.org/poky
 

Checkout latest realease (https://www.yoctoproject.org/software-overview/downloads/)

 cd poky
 git checkout kirkstone

Init bild env

 source oe-init-build-env
 

Local conf file

 vim poky/build/conf/local.conf
 

Adding this statement deletes the work directory used for building a recipe once the recipe is built.

 INHERIT += "rm_work"
 

By default, the target machine for the build is qemux86. This default is easily changed through the MACHINE variable so that you can quickly build an image for a different machine.

The default local.conf file selects the RPM package manager. You can control this configuration by using the PACKAGE_CLASSES variable. For additional package manager selection information, see the “package*.bbclass” section in the Yocto Project Reference Manual.

Start the build

bitbake core-image-sato

The following steps show how easy it is to set up to build an image for a new machine. These steps build an image for the MinnowBoard MAX, which is supported by the Yocto Project and the meta-intel intel-corei7-64 and intel-core2-32 Board Support Packages (BSPs).

Create a Local Copy of the meta-intel Repository

git clone git://git.yoctoproject.org/meta-intel

For RPi4

git clone git://git.yoctoproject.org/meta-raspberrypi

See other hardware layer here https://git.yoctoproject.org/

Configure the Build: To configure the build, you edit the bblayers.conf and local.conf files, both of which are located in the build/conf directory.

Here is a quick way to make the edits. The first command uses the bitbake-layers add-layer command to add the meta-intel layer, which contains the intel-core* BSPs to the build. The second command selects the BSP by setting the MACHINE variable.

 bitbake-layers add-layer "$HOME/source/poky/meta-intel"
 echo 'MACHINE = "intel-corei7-64"' >> conf/local.conf

• https://www.yoctoproject.org/docs/2.4.4/bsp-guide/bsp-guide.html#bsp

You can see the BSP layers in the Yocto Project Source Repositories through a web interface at http://git.yoctoproject.org/cgit/cgit.cgi. If you go to that interface, you will find near the bottom of the list under “Yocto Metadata Layers” several BSP layers all of which are supported by the Yocto Project (e.g. meta-raspberrypi and meta-intel). Each of these layers is a repository unto itself and clicking on a layer reveals information that includes two links from which you can choose to set up a clone of the layer's repository on your local host system. Here is an example that clones the Raspberry Pi BSP layer:

 git clone git://git.yoctoproject.org/meta-raspberrypi
 git checkout kirkstone

Hardware Configuration Options You can find these files in the BSP Layer at:

 meta-bsp_name/conf/machine/*.conf
                

The machine files bind together all the information contained elsewhere in the BSP into a format that the build system can understand. If the BSP supports multiple machines, multiple machine configuration files can be present. These filenames correspond to the values to which users have set the MACHINE variable, e.g, raspberrypi4-64.

  vim meta-raspberrypi/conf/machine/raspberrypi
  raspberrypi0-2w-64.conf  raspberrypi0-wifi.conf   raspberrypi3.conf        raspberrypi-cm3.conf
  raspberrypi0-2w.conf     raspberrypi2.conf        raspberrypi4-64.conf     raspberrypi-cm.conf
  raspberrypi0.conf        raspberrypi3-64.conf     raspberrypi4.conf        raspberrypi.conf  

 bitbake core-image-minimal
                

Once the build completes, the resulting basic console image is located in the Build Directory here:

 tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.hddimg
 

Write the Image: You can write the image to a USB key, SATA drive, or SD card by using the mkefidisk.sh script, which is included in the poky repository at scripts/contrib/mkefidisk.sh:

 $ sudo $HOME/source/poky/scripts/contrib/mkefidisk.sh HOST_DEVICE \
    tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.hddimg TARGET_DEVICE
                

In the previous command, HOSTDEVICE is the device node on the build host (e.g. /dev/sdc or /dev/mmcblk0). TARGETDEVICE is the name of the device as the MinnowBoard MAX sees it (e.g. /dev/sda or /dev/mmcblk0).

• layer index https://layers.openembedded.org/layerindex/branch/master/layer/meta-java/

• https://layers.openembedded.org/layerindex/branch/master/layer/meta-java/

You should define at least the following variables in a distro include file or local.conf

# Possible provider: cacao-initial-native and jamvm-initial-native
PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"

# Possible provider: cacao-native and jamvm-native
PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"

# Optional since there is only one provider for now
PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

IMAGE_INSTALL:append = " openjdk-8"

Simply rely on openjdk-7-jre, openjdk-7, openjdk-8 or openjre-8.

For conf/bblayers.conf you have to add

BBLAYERS ?= " \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-poky \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-yocto-bsp \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-raspberrypi \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-openembedded/meta-python \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-openembedded/meta-oe \
  /home/osboxes/workspace/yocto/rpi4/edgegw/layers/poky/meta-java \
  "

• https://hub.mender.io/t/how-to-create-custom-images-using-yocto-project/902

• https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Setting-up-the-Eclipse-IDE-for-Yocto-Application-Development/ta-p/1110480

You can easily list all the targets/recipes (.bb files) in your workspace doing:

bitbake-layers show-recipes

If you want only the recipes for your image, do:

bitbake-layers show-recipes "<image_name>"

Extend partition of the image.

• https://groups.google.com/a/lists.mender.io/g/mender/c/gHRj0qL0BfU?pli=1
• https://www.linkedin.com/pulse/getting-started-embedded-linux-yocto-project-building-ahmed-kassem/

Script mode -s

echo “Resize rootfs partition to take the whole sd.img size”

 	
  parted -s sd.img resizepart 2 100%
  parted /dev/mmcblk1 resizepart 4 100% -s
  resize2fs /dev/mmcblk1p4
  

Command: resizepart number end

Moves the end position of partition number. Note that this does not modify any filesystem present in the partition. If you wish to do this, you will need to use external tools, such as resize2fs.

When growing a partition you will want to grow the filesystem afterwards, but when shrinking, you need to shrink the filesystem before the partition.

“End” is the GB from the beginning of the disk, e.g., 120GB position on 128GB disk.

Interactive mode

(parted) print free
Model: WDC CL SN520 SDAPMUW-128G-1022 (nvme)
Disk /dev/nvme0n1: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name       Flags
        17.4kB  1049kB  1031kB  Free Space
 1      1049kB  135MB   134MB   fat16        msdos      legacy_boot, msftdata
 2      135MB   21.6GB  21.5GB  ext4         platform
 3      21.6GB  43.1GB  21.5GB  ext4         platform2
 4      43.1GB  64.0GB  20.9GB  ext4         data
        64.0GB  128GB   64.0GB  Free Space

(parted) resizepart
Partition number? 4
Warning: Partition /dev/nvme0n1p4 is being used. Are you sure you want to continue?
Yes/No? yes
End?  [64.0GB]? 120GB
(parted) print free
Model: WDC CL SN520 SDAPMUW-128G-1022 (nvme)
Disk /dev/nvme0n1: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name       Flags
        17.4kB  1049kB  1031kB  Free Space
 1      1049kB  135MB   134MB   fat16        msdos      legacy_boot, msftdata
 2      135MB   21.6GB  21.5GB  ext4         platform
 3      21.6GB  43.1GB  21.5GB  ext4         platform2
 4      43.1GB  120GB   76.9GB  ext4         data
        120GB   128GB   8036MB  Free Space