Difference between revisions of "RZ-G/RZG2 yocto"

From eLinux.org
Jump to: navigation, search
(Added "Fix the VLP64 v1.0.5-RT SDK Toolchain")
(moved some content to page RZ-G/RZG2_BSP)
(2 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
= BSP Differences Between renesas.com Download and Github Version =
 
= BSP Differences Between renesas.com Download and Github Version =
Below are the differences between BSP you download from renesas.com and what is available on public repositories.
 
 
'''Public Repository Clones'''<br>
 
* meta-gplv2/
 
* meta-linaro/
 
* meta-openembedded/
 
* meta-qt5/
 
* meta-rzg2/
 
* meta-virtualization/
 
* poky/
 
These directories are direct clones (no modifications) from public repositories. The repository URLs and commit IDs that were used are documented in the [https://github.com/renesas-rz/meta-rzg2/blob/master/README.md README.md] file in the meta-rzg2 directory in the BSP.
 
 
 
'''Example Layers'''<br>
 
* meta-hmi-custom/
 
* meta-userboard/
 
These directories do not have any functionally. They are simple example templates you can use to make your own customer layers. They are only included in the renesas.com package.
 
 
 
'''The RZ/G2 BSP'''<br>
 
* meta-rzg2/
 
Basically, all the customizations and patches are located in the directory 'meta-rzg2'.<br>
 
This directory is a clone of the public repository is located here: https://github.com/renesas-rz/meta-rzg2.<br>
 
There are git tags for BSP version that was release.<br>
 
The only difference is that in the renesas.com version, the following lines were added to the local.conf files under docs/sample/conf
 
: DL_DIR = "${TOPDIR}/oss_packages"
 
: BB_NO_NETWORK = "0"
 
Additionally, other configuration files such as bblayers_gecko.conf and local_gecko.con are added to the renesas.com download that are not in the github version.
 
 
 
'''Non-public Patches'''<br>
 
* extra/
 
This directory is only in the package downloaded from renesa.com<br>
 
It contains patches that are not included in the public the meta-rzg2 repository on github. For example, the patches to enable HDMI on the boards were not posted to github because of potential license issues.
 
 
 
'''Video and Multi-media Drivers'''<br>
 
* proprietary/
 
This directory is only in the package downloaded from renesa.com<br>
 
This directory contains .zip files which are essentially the propriety closed source video and multimedia drivers. They used to be downloaded separately, but are now included when downloaded the BSP from renesas.com. When following the instructions in the "Renesas Note" that comes with the BSP, users will run the script copy_proprietary_softwares.sh which will unpack these zip files into various directories under meta-rzg2.
 
  
 +
(moved to [[RZ-G/RZG2_BSP]] )
  
 
= Online vs Offline Yocto build =
 
= Online vs Offline Yocto build =
Line 188: Line 149:
  
 
= Fix the VLP64 v1.0.5-RT SDK Toolchain =
 
= Fix the VLP64 v1.0.5-RT SDK Toolchain =
 +
( moved to [[RZ-G/RZG2_BSP]] )
 +
 +
= Fix RZ/G2H eMMC boot for VLP64 v1.0.5-RT and v1.0.6 =
 +
( moved to [[RZ-G/RZG2_BSP]] )
 +
 +
= How to add any files in rootfs with yocto  =
 +
 +
If you have a file or files and you want this file to be present on the root file system. There are two steps for this:
 +
<pre>
 +
1. Create a recipe
 +
2. Add this recipe into your local.conf file
 +
</pre>
 +
There are different ways to add new recipes to Yocto.
 +
One way is to simply create a new recipe_version.bb file within one of the existing layers used by Yocto.
 +
Another preferred method for adding recipes to the build environment is to place them within a new layer.
 +
 +
For this post, let's consider you want to copy a script file to bin folder of root file system.
 +
Also create your own layer to add recipe to the build.
  
When the V1.0.5-RT BSP was released, there was a bug when creating the SDK toolchain.
+
1. Create your own layer called "meta-custom" using the bitbake-layers create-layer command.
When using the SDK toolchain created by the v1.0.5-RT BSP to build a user application, you may get warning and error messages that the linker cannot find library files that you know exits.
+
<pre>
For example:
+
$cd build
 +
$bitbake-layers create-layer ../meta-custom
 +
</pre>
 +
The command automates layer creation by setting up a subdirectory with a layer.conf configuration file, a recipes-example subdirectory that contains an example.bb recipe, a licensing file, and a README.
 
<pre>
 
<pre>
real-ld: warning: libm.so.6, needed by /opt/poky/2.4.3/sysroots/aarch64-poky-linux/usr/lib64/libwayland-client.so, not found (try using -rpath or -rpath-link)
+
../meta-custom
 +
├── conf
 +
│  └── layer.conf
 +
├── COPYING.MIT
 +
├── README
 +
└── recipes-example
 +
    └── example
 +
        └── example_0.1.bb
 
</pre>
 
</pre>
 +
After that you can add the newly created layer to the Yocto Project environment in conf/bblayers.conf:
 +
 +
${TOPDIR}/../meta-custom \
 +
 +
There is also a command to add a new layer to bblayer.conf:  bitbake-layers add-layer.
 +
 +
But this includes the meta layer with absolute paths, which can be avoided by adding it manually.
 +
 +
 +
2. Create your recipe called 'recipes-app' folder inside your own 'meta-custom' layer
 +
 +
 +
3. In 'recipes-app' folder create a new folder named  as per your requirement, for example 'echo-hello-world'
  
This bug came as the result of using the binutils version that we import from the Debina Buster repository as part of the CIP core.
 
There were 2 patches that were added to teh Debian repository that do not work well with ARM64 builds under Yocto.
 
The fix is to simply remove the code that was added by those those 2 Debian patches.
 
You can read more about it here: https://github.com/renesas-rz/meta-rzg2/commit/2a6153c80d59
 
  
The Renesas VLP64 v1.0.6 BSP has this fix, but the v1.0.5-RT BSP does not.
+
4. cd into the 'echo-hello-world' and then create a folder named 'files' into that
  
Below are the instructions to fix your existing v1.0.5-RT BSP.
 
  
1. Open a terminal in your v1.05-RT Yocto directory and change into the meta-rzg2 directory.
+
5. copy your script file "hello.sh" into the files folder. Also add a licensing file.  
 
<pre>
 
<pre>
$ cd /x/x/x/rzg2_bsp_eva_v105rt
+
#!/bin/bash
$ cd meta-rzg2
+
var="Hello World"
 +
# print it
 +
echo "$var"
 
</pre>
 
</pre>
  
2. Download the specific commit (as a patch file) from the meta-rzg2 repository that was added to fix this issue for the v1.0.6 BSP release.
+
6. cd back to the 'echo-hello-world' folder and create a file named 'echo-hello-world_1.0.bb'(recipe_version.bb)
 
<pre>
 
<pre>
$ wget https://github.com/renesas-rz/meta-rzg2/commit/2a6153c80d59.patch
+
../meta-custom
 +
├── conf
 +
│  ├── bitbake-cookerdaemon.log
 +
│  └── layer.conf
 +
├── COPYING.MIT
 +
├── README
 +
├── recipes-app
 +
│  └── echo-hello-world
 +
│      ├── echo-hello-world_1.0.bb
 +
│      └── files
 +
│          ├── COPYING
 +
│          └── hello.sh
 +
└── recipes-example
 +
    └── example
 +
        └── example.bb
 
</pre>
 
</pre>
  
3. Apply the patch. Between the v1.0.5-RT and v1.0.6 BSP, the directory "meta-rzg2/cip-core-buster/cip-core-buster-limited/binutils" was moved into "meta-rzg2/recipes-cip-core/buster-limited/binutils".
+
7. copy the recipe in echo-hello-world_1.0.bb
Therefore when we apply the patch, we need to change into the subdirecotry and then strip down the path from the patch file (-p3).
 
Also, we can ignore the whitespace warnings because we are applying a patch that creates new patch files (that will have trailing white spaces), which is a little confusing for 'git apply'.
 
 
<pre>
 
<pre>
$ cd cip-core-buster/cip-core-buster-limited
+
SUMMARY = "Hello World echo script"
$ git apply -p3 --whitespace=nowarn ../../2a6153c80d59.patch
+
LICENSE = "MIT"
$ cd ../..
+
LIC_FILES_CHKSUM = "file://COPYING;md5=a70b80ed7aa06ee4bc60901a9e98d373"
 +
 
 +
SRC_URI = " \
 +
file://COPYING \
 +
file://hello.sh \
 +
"
 +
 
 +
S = "${WORKDIR}"
 +
 
 +
do_install () {
 +
    # create the /usr/bin folder in the rootfs with default permissions
 +
    install -d ${D}${bindir}
 +
    # install the application into the /usr/bin folder
 +
    install -m 0755 ${S}/hello.sh ${D}${bindir}
 +
}
 +
RDEPENDS_${PN} += "bash"
 
</pre>
 
</pre>
  
4. Do a complete rebuild of the binutils that is used in the SDK (binutils-cross-canadian-aarch64) and then recreate SDK itself.
+
8. Add the following line into local.conf :
<pre>
+
 
$ bitbake binutils-cross-canadian-aarch64 -c clean
+
IMAGE_INSTALL_append = " echo-hello-world"
$ bitbake binutils-cross-canadian-aarch64 -c cleansstate
+
 
$ bitbake binutils-cross-canadian-aarch64
 
$ bitbake core-image-qt-sdk -c populate_sdk
 
</pre>
 
  
5. Finally, reinstall the SDK. As always, your SDK is located in build/tmp/deploy/sdk/
+
After board boot up, you can see your script file in /usr/bin as:
 
<pre>
 
<pre>
$ sudo ./poky-glibc-x86_64-core-image-qt-sdk-aarch64-toolchain-2.4.3.sh
+
root@hihope-rzg2m:/usr/bin# ls | grep hello.sh
 +
hello.sh
 +
root@hihope-rzg2m:/usr/bin# ./hello.sh  
 +
Hello World
 
</pre>
 
</pre>

Revision as of 11:46, 18 February 2021

BSP Differences Between renesas.com Download and Github Version

(moved to RZ-G/RZG2_BSP )

Online vs Offline Yocto build

The RZ/G VLP download includes a number of packages named 'OSS package xxx' that contain most of the source code that will be used during the Linux BSP build. The user can download those packages and then run an 'offline' Yocto build, which means that Yocto won't download any source code during the build. However, dealing with the 'OSS' packages is quite inconvenient - the user needs to download 10 to 15 large binary files, then merge them into one very large file, and then transfer that file to the build environment. There are also some limitations to the 'offline' build, for example some packages cannot be built that way.

For that reason we recommend doing an 'online' Yocto build, which is the most typical way those builds are done. There is no need to download the 'OSS' packages in this case. The only thing that is required is checking your local.conf file and making sure that a couple of variables are set correctly. The two variables are 'DL_DIR' - needs to be commented out, and BB_NO_NETWORK - needs to be set to 0.

#DL_DIR = "${TOPDIR}/oss_packages"BB_NO_NETWORK = "0" 
BB_NO_NETWORK = "0"

Hello World Example

Yocto has an example of how to create a simple Hello World application using the SDK that you created/installed on your machine.

https://www.yoctoproject.org/docs/2.4/sdk-manual/sdk-manual.html#sdk-working-projects

Helpful Packages to Include

These packages are not part of the default Yocto BSP build, but they might be helpful to add to your build. Simple add them to your local.conf file.

devmem2 can be used to read RZ/G registers from command line

IMAGE_INSTALL_append = " devmem2"

i2c-tools can be used to read/write to I2C devices from the command line

IMAGE_INSTALL_append = " i2c-tools"

libgpiod can be used to read/write to GPIOs from the command line and from application code

IMAGE_INSTALL_append = " libgpiod" 


Making the Yocto SDK and the '-sdk' root filesystem images smaller

When building the Yocto SDK or one of the '-sdk' images, e.g. 'core-image-weson-sdk', the default configuration includes the source code for most packages which makes the generated images install very big. Generally, you don't need this code outside of Yocto build environment, but some of the Renesas BSP recipes include it. Adding this line below will make your SDK much smaller.

# Do not include "dbg-pkgs" in SDK Installs 
SDKIMAGE_FEATURES_remove = " dbg-pkgs" 

If the SDK is not going to be used for building out-of-tree kernel modules, the kernel source code does not need to be included in it. Removing that reduces the size of the SDK significantly. The line below also removes the 'ltp' package, which is a Linux testing framework that is not needed in most cases.

IMAGE_INSTALL_remove = " kernel-devsrc ltp"  


Common Yocto Build Issues

1) Fixing build issues It often happens that some packages fail while building, e.g.:

ERROR: python3-pytorch-1.5.0-r0 do_configure: oe_runmake failed 
ERROR: python3-pytorch-1.5.0-r0 do_configure: Function failed: do_configure (log file is located at ...) 
ERROR: Logfile of failure stored in: ... 

This kind of errors can be easily fixed by cleaning up :

bitbake –c cleansstate python3-pythorch 

And retrying.

2) Fix bitbake error Invoking bitbake may result in a weird error:

OSError: Cannot initialize new instance of inotify, Errno=Too many open files (EMFILE) 

It is possible to overcome this error by giving this command:

sudo sh -c "echo 8192 > /proc/sys/fs/inotify/max_user_instances" 


Build DTB only with Yocto

If you have modified your Device Tree Source file (.dts) and just want to rebuild only that file (not the entire kernel) to create a new Device Tree Binary (.dtb) file, you can do the following steps.
Open a "development shell" for the Linux kernel:

bitbake linux-renesas -c devshell

Once in the shell, enter this command to have the kernel rebuild the Device Tree Binaries:

make dtbs 

To exit the 'devshell' window, just type exit.

exit

Even though you have rebuilt your device files inside the devshell, the output files are still located deep inside the Yocto directories (build/tmp/work/hihope_rzg2m-poky-linux/linux-renesas/xxx/xxx/xxx/xxx)
Therefore, execute the following command (outside of devshell) in order to copy them to the default "deploy" directory.

bitbake linux-renesas -fc deploy

Using Header Files and Shared Libraries in Applications

When you add a library to your Yocto build such as libgpio ( IMAGE_INSTALL_append = " libgpiod" ) and then build an SDK with it (bitbake core-image-weston-sdk -c populate_sdk), the appropriate share library file (.so) and header files (.h) will be added to the 'sysroot' directory in you toolchain.

For example:

$ find /opt/poky/2.4.3 -name gpiod.h
/opt/poky/2.4.3/sysroots/aarch64-poky-linux/usr/include/gpiod.h

$ find /opt/poky/2.4.3 -name "libgpiod.*"
/opt/poky/2.4.3/sysroots/aarch64-poky-linux/usr/lib64/libgpiod.so
/opt/poky/2.4.3/sysroots/aarch64-poky-linux/usr/lib64/libgpiod.so.0
/opt/poky/2.4.3/sysroots/aarch64-poky-linux/usr/lib64/libgpiod.so.0.3.1

Then in your application, you can add #include <gpiod.h> to have access to those library functions.

However, when you build your application with gcc, you need to: 1) Tell gcc where to find the header file.

Use the gcc option " -I " to add an include patch to your gcc command line.

"SDKTARGETSYSROOT" will be defined by the yocto SDK.

-I $SDKTARGETSYSROOT/usr/include

2) Tell gcc that the share library libgpio is required by the application using the -l argument. For libgpio, that would be "-lgpio"

For example:

aarch64-poky-linux-gcc -lgpiod -march=armv8-a -mtune=cortex-a57.cortex-a53 --sysroot=$SDKTARGETSYSROOT -I $SDKTARGETSYSROOT -O2 -pipe -g -feliminate-unused-debug-types -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed hello1.c -o hello1

Building Webviewer

Webviewer is the RZ/G2 lightweight GPU optimized browser we recommend for HTML5 GUIs. It is not included in the VLP by default but you need Gecko to be there as pre-requisite (see VLP release note about how to add it).

git clone https://github.com/webdino/meta-browser

in the user_work directory (or whenever the other VLP meta layers are). Change the local.conf (/user_work/build/conf) to have "firefox" replaced with "webviewer":

IMAGE_INSTALL_append = “ webviewer “ 
IMAGE_INSTALL_append = “ ttf-sazanami-gothic ttf-sazanami-mincho “ 
PACKAGECONFIG_append_pn-webviewer = “ egl “ 
PACKAGECONFIG_append_pn-webviewer = “ openmax “ 
PACKAGECONFIG_append_pn-webviewer = “ webgl “ 
PACKAGECONFIG_append_pn-webviewer = “ canvas-gpu “ 
PACKAGECONFIG_append_pn-webviewer = “ stylo “ 

Add the meta-layer to the bblayers.conf:

BBLAYERS += " ${TOPDIR}/../meta-browser " 
Optionally you can include the Gem Tanzanite demo: 
BBLAYERS += " ${TOPDIR}/../meta-gecko-embedded/meta-demo " 

And in the local.conf:

IMAGE_INSTALL_append = " gem-tanzanite " 

The file /usr/bin/gem-tanzanite.sh shall be modified as well, replacing firefox with webviewer. Then the demo can then be started by typing the command:

gem-tanzanite

Note that the demo can be navigated only by using a touch-enabled monitor (no mouse). If you know what you're doing you can hack the app.js in the js folder to turn the touch events into mouse events.

Fix the VLP64 v1.0.5-RT SDK Toolchain

( moved to RZ-G/RZG2_BSP )

Fix RZ/G2H eMMC boot for VLP64 v1.0.5-RT and v1.0.6

( moved to RZ-G/RZG2_BSP )

How to add any files in rootfs with yocto

If you have a file or files and you want this file to be present on the root file system. There are two steps for this:

1. Create a recipe
2. Add this recipe into your local.conf file

There are different ways to add new recipes to Yocto. One way is to simply create a new recipe_version.bb file within one of the existing layers used by Yocto. Another preferred method for adding recipes to the build environment is to place them within a new layer.

For this post, let's consider you want to copy a script file to bin folder of root file system. Also create your own layer to add recipe to the build.

1. Create your own layer called "meta-custom" using the bitbake-layers create-layer command.

$cd build
$bitbake-layers create-layer ../meta-custom

The command automates layer creation by setting up a subdirectory with a layer.conf configuration file, a recipes-example subdirectory that contains an example.bb recipe, a licensing file, and a README.

../meta-custom
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
└── recipes-example
    └── example
        └── example_0.1.bb

After that you can add the newly created layer to the Yocto Project environment in conf/bblayers.conf:

${TOPDIR}/../meta-custom \

There is also a command to add a new layer to bblayer.conf: bitbake-layers add-layer.

But this includes the meta layer with absolute paths, which can be avoided by adding it manually.


2. Create your recipe called 'recipes-app' folder inside your own 'meta-custom' layer


3. In 'recipes-app' folder create a new folder named as per your requirement, for example 'echo-hello-world'


4. cd into the 'echo-hello-world' and then create a folder named 'files' into that


5. copy your script file "hello.sh" into the files folder. Also add a licensing file.

#!/bin/bash
var="Hello World"
# print it 
echo "$var"

6. cd back to the 'echo-hello-world' folder and create a file named 'echo-hello-world_1.0.bb'(recipe_version.bb)

../meta-custom
├── conf
│   ├── bitbake-cookerdaemon.log
│   └── layer.conf
├── COPYING.MIT
├── README
├── recipes-app
│   └── echo-hello-world
│       ├── echo-hello-world_1.0.bb
│       └── files
│           ├── COPYING
│           └── hello.sh
└── recipes-example
    └── example
        └── example.bb

7. copy the recipe in echo-hello-world_1.0.bb

SUMMARY = "Hello World echo script"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=a70b80ed7aa06ee4bc60901a9e98d373"

SRC_URI = " \
file://COPYING \
file://hello.sh \
"

S = "${WORKDIR}"

do_install () {
    # create the /usr/bin folder in the rootfs with default permissions
    install -d ${D}${bindir}
    # install the application into the /usr/bin folder
    install -m 0755 ${S}/hello.sh ${D}${bindir}
}
RDEPENDS_${PN} += "bash"

8. Add the following line into local.conf :

IMAGE_INSTALL_append = " echo-hello-world"


After board boot up, you can see your script file in /usr/bin as:

root@hihope-rzg2m:/usr/bin# ls | grep hello.sh 
hello.sh
root@hihope-rzg2m:/usr/bin# ./hello.sh 
Hello World