Dear all,

I am using RZ/G2M evaluation board, as i saw  demo videos of face recognition in youtube , i am trying to download face recognition application  for rz/g2m in renesas market place but i am not able find, please share me link to download the face recognition software for rz/g2m 

  • Are you talking about face recognition or face detection?

    You can refer to this demo for the face detection:


    and use the face dataset instead of the COCO dataset.

  • Thanks for the reply,

    i will try the above in my RZ/G2M eval board

    i have downloaded  meta-renesas-ai-4.0.0 from the renesas wesite and i have copied

    meta-renesas-ai/meta-benchmark/templates/<Board>/local.conf and bblayer.conf to my conf dir and i have started building
    giving the command bitbake core-image-qt-sdk

    i am trying to enable required AI packages in my rootfile system and then i will try to install the

    the above steps which i am trying is correct or not plz let me know waiting for your reply

    Thanks & regards
    Mahesh R
  • Looks ok to me.

    And yes, it takes a while...

  • Thank you, i will let you know the response

  • Hi MicBis,

    i'am getting an error,PLZ refer the errors in the attached image

    please help me to solve this issue,

    Thanks & regards

    Mahesh R

  • Without looking at the logs, you can try to clean:

    bitbake NAME_OF_THE_PACKAGE -c cleansstate

    And rebuild.

  • Hello Mahesh,

    Can you confirm what you are trying to build?

    It looks to me like you're trying to build the RZ/G AI BSP? (meta-renesas-ai), but originally you said you wanted to build the object (&face) detection demo?

    If you want to build the object detection demo (there is the option to use a facial detection model), I suggest you use the Yocto layers found in meta-renesas-ai-demos.

    Complete build instructions can be found in the object detection demo's README.

    Alternatively, if you want to continue with your current build, please share your local.conf and bblayers.conf files, as well as the log.do_configure file referenced in your screen shot, and we'll see if there are any obvious issues.


  • Thanks for your reply,

    I wanted to enable and run  AI - applications in RZ/G2M board, which i have seen demo in youtube and other different platform.

    I will also try your suggestions object detection demo's README.

    As per the instructions from MicBis i have downloaded meta-renesas-ai-4.0.0 from the renesas wesite and included in the BSP, as README.md file of meta-renesas-ai-4.0.0 tell to copy

    meta-renesas-ai/meta-benchmark/templates/<Board>/local.conf and bblayers.conf and 
    run bitbake core-image-qt-sdk

    i followed all the instruction in README.md file but i'am getting errors.

    please find the attached local.conf and bblayers.conf and

    # This file is your local configuration file and is where all local user settings
    # are placed. The comments in this file give some guide to the options a new user
    # to the system might want to change but pretty much any configuration option can
    # be set in this file. More adventurous users can look at local.conf.extended
    # which contains other examples of configuration which can be placed in this file
    # but new users likely won't need any of them initially.
    # Lines starting with the '#' character are commented out and in some cases the
    # default values are provided as comments to show people example syntax. Enabling
    # the option is a question of removing the # character and making any change to the
    # variable as required.

    # Machine Selection
    # You need to select a specific machine to target the build with. There are a selection
    # of emulated machines available which can boot and run in the QEMU emulator:
    #MACHINE ?= "qemuarm"
    #MACHINE ?= "qemuarm64"
    #MACHINE ?= "qemumips"
    #MACHINE ?= "qemumips64"
    #MACHINE ?= "qemuppc"
    #MACHINE ?= "qemux86"
    #MACHINE ?= "qemux86-64"
    # There are also the following hardware board target machines included for
    # demonstration purposes:
    #MACHINE ?= "beaglebone"
    #MACHINE ?= "genericx86"
    #MACHINE ?= "genericx86-64"
    #MACHINE ?= "mpc8315e-rdb"
    #MACHINE ?= "edgerouter"
    # This sets the default machine to be qemux86 if no other machine is selected:
    MACHINE ??= "hihope-rzg2m"

    # Where to place downloads
    # During a first build the system will download many different source code tarballs
    # from various upstream projects. This can take a while, particularly if your network
    # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
    # can preserve this directory to speed up this part of subsequent builds. This directory
    # is safe to share between multiple builds on the same machine too.
    # The default is a downloads directory under TOPDIR which is the build directory.
    #DL_DIR ?= "${TOPDIR}/downloads"

    # Where to place shared-state files
    # BitBake has the capability to accelerate builds based on previously built output.
    # This is done using "shared state" files which can be thought of as cache objects
    # and this option determines where those files are placed.
    # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
    # from these files if no changes were made to the configuration. If changes were made
    # to the configuration, only shared state files where the state was still valid would
    # be used (done using checksums).
    # The default is a sstate-cache directory under TOPDIR.
    #SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
    # Default to setting automatically based on cpu count
    PARALLEL_MAKE ?= "-j 3"
    # Where to place the build output
    # This option specifies where the bulk of the building work should be done and
    # where BitBake should place its temporary files and output. Keep in mind that
    # this includes the extraction and compilation of many applications and the toolchain
    # which can use Gigabytes of hard disk space.
    # The default is a tmp directory under TOPDIR.
    #TMPDIR = "${TOPDIR}/tmp"

    # Default policy config
    # The distribution setting controls which policy settings are used as defaults.
    # The default value is fine for general Yocto project use, at least initially.
    # Ultimately when creating custom policy, people will likely end up subclassing
    # these defaults.
    DISTRO ?= "poky"
    # As an example of a subclass there is a "bleeding" edge policy configuration
    # where many versions are set to the absolute latest code from the upstream
    # source control systems. This is just mentioned here as an example, its not
    # useful to most new users.
    # DISTRO ?= "poky-bleeding"

    # Package Management configuration
    # This variable lists which packaging formats to enable. Multiple package backends
    # can be enabled at once and the first item listed in the variable will be used
    # to generate the root filesystems.
    # Options are:
    # - 'package_deb' for debian style deb files
    # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
    # - 'package_rpm' for rpm style packages
    # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
    # We default to rpm:
    PACKAGE_CLASSES ?= "package_rpm"

    # SDK target architecture
    # This variable specifies the architecture to build SDK items for and means
    # you can build the SDK packages for architectures other than the machine you are
    # running the build on (i.e. building i686 packages on an x86_64 host).
    # Supported values are i686 and x86_64
    #SDKMACHINE ?= "i686"

    # Extra image configuration defaults
    # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
    # images. Some of these options are added to certain image types automatically. The
    # variable can contain the following options:
    # "dbg-pkgs" - add -dbg packages for all installed packages
    # (adds symbol information for debugging/profiling)
    # "dev-pkgs" - add -dev packages for all installed packages
    # (useful if you want to develop against libs in the image)
    # "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
    # (useful if you want to run the package test suites)
    # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
    # "tools-debug" - add debugging tools (gdb, strace)
    # "eclipse-debug" - add Eclipse remote debugging support
    # "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
    # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
    # "debug-tweaks" - make an image suitable for development
    # e.g. ssh root access has a blank password
    # There are other application targets that can be used here too, see
    # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
    # We default to enabling the debugging tweaks.
    EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

    # Additional image features
    # The following is a list of additional classes to use when building images which
    # enable extra features. Some available options which can be included in this variable
    # are:
    # - 'buildstats' collect build statistics
    # - 'image-mklibs' to reduce shared library files size for an image
    # - 'image-prelink' in order to prelink the filesystem image
    # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
    # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
    USER_CLASSES ?= "buildstats image-mklibs image-prelink"

    # Runtime testing of images
    # The build system can test booting virtual machine images under qemu (an emulator)
    # after any root filesystems are created and run tests against those images. To
    # enable this uncomment this line. See classes/testimage(-auto).bbclass for
    # further details.
    #TEST_IMAGE = "1"
    # Interactive shell configuration
    # Under certain circumstances the system may need input from you and to do this it
    # can launch an interactive shell. It needs to do this since the build is
    # multithreaded and needs to be able to handle the case where more than one parallel
    # process may require the user's attention. The default is iterate over the available
    # terminal types to find one that works.
    # Examples of the occasions this may happen are when resolving patches which cannot
    # be applied, to use the devshell or the kernel menuconfig
    # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
    # Note: currently, Konsole support only works for KDE 3.x due to the way
    # newer Konsole versions behave
    #OE_TERMINAL = "auto"
    # By default disable interactive patch resolution (tasks will just fail instead):
    PATCHRESOLVE = "noop"

    # Disk Space Monitoring during the build
    # Monitor the disk space during the build. If there is less that 1GB of space or less
    # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
    # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
    # of the build. The reason for this is that running completely out of space can corrupt
    # files and damages the build in ways which may not be easily recoverable.
    # It's necesary to monitor /tmp, if there is no space left the build will fail
    # with very exotic errors.
    BB_DISKMON_DIRS ??= "\
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \

    # Shared-state files from other locations
    # As mentioned above, shared state files are prebuilt cache data objects which can
    # used to accelerate build time. This variable can be used to configure the system
    # to search other mirror locations for these objects before it builds the data itself.
    # This can be a filesystem directory, or a remote url such as http or ftp. These
    # would contain the sstate-cache results from previous builds (possibly from other
    # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
    # cache locations to check for the shared objects.
    # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
    # at the end as shown in the examples below. This will be substituted with the
    # correct path within the directory structure.
    #file://.* someserver.tld/.../PATH;downloadfilename=PATH \n \
    #file://.* file:///some/local/dir/sstate/PATH"

    # Qemu configuration
    # By default qemu will build with a builtin VNC server where graphical output can be
    # seen. The two lines below enable the SDL backend too. By default libsdl-native will
    # be built, if you want to use your host's libSDL instead of the minimal libsdl built
    # by libsdl-native then uncomment the ASSUME_PROVIDED line below.
    PACKAGECONFIG_append_pn-qemu-native = " sdl"
    PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
    #ASSUME_PROVIDED += "libsdl-native"

    # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
    # track the version of this file when it was generated. This can safely be ignored if
    # this doesn't mean anything to you.
    CONF_VERSION = "1"

    # Add systemd configuration
    DISTRO_FEATURES_append = " systemd"
    VIRTUAL-RUNTIME_init_manager = "systemd"

    # Linaro GCC
    GCCVERSION = "linaro-7.3"

    # add the static lib to SDK toolchain
    SDKIMAGE_FEATURES_append = " staticdev-pkgs"

    # Disable optee in meta-linaro layer
    BBMASK = "meta-linaro/meta-optee/recipes-security/optee"

    # Enable Gfx Pkgs
    MACHINE_FEATURES_append = " gsx"
    MULTI_PROVIDER_WHITELIST += "virtual/libgl virtual/egl virtual/libgles1 virtual/libgles2"

    # for Wayland/Weston
    DISTRO_FEATURES_NATIVESDK_append = " wayland"
    DISTRO_FEATURES_append = " pam"
    PREFERRED_PROVIDER_virtual/libgles1 = ""
    PREFERRED_PROVIDER_virtual/libgles2 = "gles-user-module"
    PREFERRED_PROVIDER_virtual/egl = "libegl"
    PREFERRED_PROVIDER_virtual/libgl = ""
    PREFERRED_PROVIDER_virtual/mesa = ""
    PREFERRED_PROVIDER_libgbm = "libgbm"
    PREFERRED_PROVIDER_libgbm-dev = "libgbm"
    BBMASK .= "|mesa-gl"

    # for non-qt building
    BBMASK .= "${@'|recipes-qt/|core-image-qt*' if 'qt5-layer' not in BBFILE_COLLECTIONS.split() else ''}"

    # Enable Multimedia features
    MACHINE_FEATURES_append = " multimedia"

    # for gstreamer omx plugins
    LICENSE_FLAGS_WHITELIST = "commercial"
    # for mmp test program
    DISTRO_FEATURES_append = " mm-test"

    # for weston v4l2 renderer
    #DISTRO_FEATURES_append = " v4l2-renderer"

    # OMX H264 decoder library for Linux (RTM0AC0000XV264D30SL41C)
    DISTRO_FEATURES_append = " h264dec_lib"

    # OMX H264 encoder library for Linux (RTM0AC0000XV264E30SL41C)
    DISTRO_FEATURES_append = " h264enc_lib"

    # OMX H265 decoder library for Linux (RTM0AC0000XV265D30SL41C)
    DISTRO_FEATURES_append = " h265dec_lib"

    # Evaluation packages
    #DISTRO_FEATURES_append = " use_eva_pkg"

    # Configuration for ivi-shell and ivi-extension
    #DISTRO_FEATURES_append = " ivi-shell"

    # Configuration for USB 3.0
    MACHINE_FEATURES_append = " usb3"

    # Disable GPLv3 and GPLv3+ Software.
    # This option should be used with meta-gplv2 which can help Yocto to search for old
    # versions which support GPLv2

    # Configuration for ECC
    # Add ecc to MACHINE_FEATURES to configure DRAM for ECC usage,
    # ECC_MODE : Full, Full Dual, Full Single, Partial
    # - Full : DRAM is configured for FULL ECC support, half of memory is reduced for storing ECC code
    # Default is Full Single for RZ/G2E, RZ/G2N, Full Dual for RZ/G2M(v1.3 & v3.0), RZ/G2H
    # - Full Dual : DRAM is configured for FULL ECC Dual channel support, half of memory is reduced for storing ECC code
    # Use only for RZ/G2M(v1.3 & v3.0) and RZ/G2H
    # - Full Single: DRAM is configured for FULL ECC Single channel support, half of memory is reduced for storing ECC code
    # Use only for RZ/G2E, RZ/G2N, RZ/G2M(v3.0) and RZ/G2H
    # - Partial: Manual add/remove ECC area by u-boot command (Default mode)
    # Example of setting:
    # MACHINE_FEATURES_append = " ecc"
    # ECC_MODE = "Partial"

    # Switch among build setting Buster-full, Buster-limited and Jessie
    # - Buster-full (default) : build all supported Debian 10 Buster recipes
    # - Buster-limited : build Debian 10 Buster, but only limited pakages similar to Jessie (4 main recipes)
    # - Jessie : build Debian 8 Jessie packages (only 4 main recipes)
    # - Not set (or different with above): not use CIP Core, use default packages version in Yocto
    CIP_MODE = "Buster-full"
    ### Adjust environment according to CIP_MODE selection. Don't change manually, only change CIP_MODE above ###
    USE_CIP_CORE = "${@'cipcore' if '${CIP_MODE}' in ['Buster-full', 'Buster-limited', 'Jessie'] else 'not-cipcore'}"
    BINUVERSION_cipcore = "${@'2.31.1' if 'Buster' in '${CIP_MODE}' else '2.25'}"
    PREFERRED_VERSION_nativesdk-binutils_cipcore = "${BINUVERSION}"
    GLIBCVERSION_cipcore = "${@'2.28' if 'Buster' in '${CIP_MODE}' else '2.19'}"
    PREFERRED_VERSION_nativesdk-glibc-locale_cipcore = "${GLIBCVERSION}"
    BBMASK_append_cipcore = "|glibc-mtrace"
    RDEPENDS_${PN}_remove_pn-packagegroup-core-tools-debug_cipcore = "libc-mtrace"
    PREFERRED_VERSION_openssl_forcevariable_cipcore = "${@'1.1.%' if 'Buster' in '${CIP_MODE}' else '1.0.%'}"
    PREFERRED_VERSION_openssl-native_forcevariable_cipcore = "${@'1.1.%' if 'Buster' in '${CIP_MODE}' else '1.0.%'}"
    PREFERRED_VERSION_nativesdk-openssl_forcevariable_cipcore = "${@'1.1.%' if 'Buster' in '${CIP_MODE}' else '1.0.%'}"
    BBMASK_append_not-cipcore = "|recipes-cip-core"
    BBMASK .= "|perl_debian"

    # Exclude LTP when building Buster
    IMAGE_INSTALL_remove += "${@'ltp' if ('${CIP_MODE}' == 'Buster-full' or '${CIP_MODE}' == 'Buster-limited') else ''}"

    # Enable multilib to support 32-bits applications.
    require conf/multilib.conf
    MULTILIBS = "multilib:lib32"
    DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf-neon-vfpv4"
    USE_32BIT_PKGS = "1"

    # Downgrade version for obexftp and openobex
    PREFERRED_VERSION_obexftp = "0.23"
    PREFERRED_VERSION_openobex = "1.5"

    # for meta-virtualization layer
    DISTRO_FEATURES_append = "${@base_conditional('VIRTUALIZATION_CHECK', 'True', ' virtualization', '', d)}"

    # Configuration for Docker
    #MACHINE_FEATURES_append = " docker"

    IMAGE_INSTALL_append = " caffe2 caffe2-dev"
    IMAGE_INSTALL_append = " tensorflow tensorflow-dev tensorflow-examples"
    IMAGE_INSTALL_append = " tensorflow-lite-staticdev tensorflow-lite-dev tensorflow-lite-examples"
    IMAGE_INSTALL_append = " armnn-dev armnn-examples \
    armnn-tensorflow-lite-dev armnn-tensorflow-lite-examples \
    armnn-tensorflow-dev armnn-tensorflow-examples \
    armnn-onnx-dev armnn-onnx-examples \
    IMAGE_INSTALL_append = " onnxruntime-staticdev onnxruntime-dev onnxruntime-examples"
    IMAGE_INSTALL_append = " opencv opencv-staticdev \
    opencv-dev opencv-apps opencv-samples \
    python-opencv \
    IMAGE_INSTALL_append = " google-coral google-coral-dev google-coral-examples"

    # Uncomment the following line to enable python-scipy, required for Inception v3 and GoogLeNet models in torchvision
    #require ${META_PYTORCH_DIR}/templates/python3-scipy/python3-scipy_RZ-G2.conf
    # GPLv3 licensed software should also be enabled by commenting out '#INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+"'
    # Please make sure you fully understand the implications of enabling license GPLv3 by reading the relevant documents (e.g. www.gnu.org/.../gpl-3.0.en.html)

    IMAGE_INSTALL_append = " python3-pytorch"

    IMAGE_INSTALL_append = " benchmark"


    # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
    # changes incompatibly

    BBPATH = "${TOPDIR}"
    BBFILES ?= ""

    QT_CHECK = "${@os.path.isdir("${TOPDIR}/../meta-qt5")}"
    VIRTUALIZATION_CHECK = "${@os.path.isdir("${TOPDIR}/../meta-virtualization")}"

    BBLAYERS ?= " \
    ${TOPDIR}/../meta-gplv2 \
    ${TOPDIR}/../poky/meta \
    ${TOPDIR}/../poky/meta-poky \
    ${TOPDIR}/../poky/meta-yocto-bsp \
    ${TOPDIR}/../meta-rzg2 \
    ${TOPDIR}/../meta-linaro/meta-linaro-toolchain \
    ${TOPDIR}/../meta-linaro/meta-optee \
    ${TOPDIR}/../meta-openembedded/meta-oe \
    ${TOPDIR}/../meta-openembedded/meta-multimedia \
    ${TOPDIR}/../meta-openembedded/meta-python \
    ${@'${TOPDIR}/../meta-qt5' if '${QT_CHECK}' == 'True' else ''} \
    ${@'${TOPDIR}/../meta-openembedded/meta-filesystems' if '${VIRTUALIZATION_CHECK}' == 'True' else ''} \
    ${@'${TOPDIR}/../meta-openembedded/meta-networking' if '${VIRTUALIZATION_CHECK}' == 'True' else ''} \
    ${@'${TOPDIR}/../meta-openembedded/meta-python' if '${VIRTUALIZATION_CHECK}' == 'True' else ''} \
    ${@'${TOPDIR}/../meta-virtualization' if '${VIRTUALIZATION_CHECK}' == 'True' else ''} \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-rzg-ai \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-armnn \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-benchmark \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-caffe2 \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-google-coral \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-onnxruntime \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-opencv \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-pytorch \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-tensorflow \
    ${TOPDIR}/../meta-renesas-ai-4.0.0/meta-tensorflow-lite \

    please help me understand what wrong i have done wrong in my BSP

  • Hello Mahesh,

    Can you share the logfile of the error you see? Yocto usually links to a logfile when there is an error.

    Are you building with bitbake core-image-qt?


  • i am using bitbake core-image-qt-sdk

    please find the log file

    DEBUG: Executing shell function do_configure
    downloading gitlab.com/.../eigen-386d809bde475c65b7940f290efe80e6a05878c4.tar.gz
    WARNING: exit code 5 from a shell command.
    ERROR: Function failed: do_configure (log file is located at /home/mahesh/RZ_G2M_tangerane/user_work/REN_rzg2_bsp_eva_v106/build/tmp/work/aarch64-poky-linux/tensorflow-lite/2.3.1-r0/temp/log.do_configure.1895)

  • Hi Mahesh,

    Is the above the entire contents of "/home/mahesh/RZ_G2M_tangerane/user_work/REN_rzg2_bsp_eva_v106/build/tmp/work/aarch64-poky-linux/tensorflow-lite/2.3.1-r0/temp/log.do_configure.1895"?

    Can you check your downloads directory to see if that eigen tarball actually downloaded okay?

    Thanks, Chris

  • Hi Chris

    Is the above the entire contents of "/home/mahesh/RZ_G2M_tangerane/user_work/REN_rzg2_bsp_eva_v106/build/tmp/work/aarch64-poky-linux/tensorflow-lite/2.3.1-r0/temp/log.do_configure.1895"?


    Can you check your downloads directory to see if that eigen tarball actually downloaded okay?

    sry which folder i need to check ?

  • Unless you've changed DL_DIR in local.conf, your downloads folder should be in the ${TOPDIR}/downloads directory (normally build/downloads).

    However, I was wrong before. The way TensorFlow/TensorFlow Lite is built it doesn't use Bitbake, it uses Bazel, so the DL_DIR won't be used.

    The script it's actually running to download those files is https://github.com/tensorflow/tensorflow/blob/v2.3.1/tensorflow/lite/tools/make/download_dependencies.sh, which will download the files to a different location.

    One thing to try is to try and directly download that eigen file with wget and see if your system can actually access it. Then check the sha256sum with the one expected (github.com/.../workspace.bzl

    If there isn't an issue there, it's likely something else if going wrong in the download_dependencies.sh script (set -e is set).

    On a side note, did you try following the object detection demo's README?