Lines Matching full:the
8 using LVGL. While the process will be demonstrated for the Raspberry Pi 3
13 You must install essential host packages on your build host. The following
14 command installs the host packages based on an Ubuntu distribution
25 For host package requirements on all supported Linux distributions, see the
26 `Required Packages for the Build Host <https://docs.yoctoproject.org/
27 ref-manual/system-requirements.html#required-packages-for-the-build-host>`_
28 section in the Yocto Project Reference Manual.
32 Use Git to clone the required repositories
34 After this section the folder tree will be like this
49 Start creating the folder architecture
55 Clone Poky, meta-openembedded and meta-raspberrypi in the sources
67 To understand better what is going on, let's build the image like it is
72 cd ../ # go back to the root folder
75 Now you should have a folder named ``build`` next to ``sources``. The last
77 also sets the current directory to the build directory.
79 In the build directory, there is a ``conf`` folder with some files in it
91 The important files for us are ``local.conf`` and ``bblayers.conf``
93 To add layers to the project there are 2 options:
97 You need to be in the same terminal you did the ``source`` command. Add the
98 layers with the Bitbake command like this
107 Open ``conf/bblayers.conf`` file and add manually the paths:
129 To ensure the layers were added as expected, run the Bitbake command to show
130 all the layers::
134 The following layers should be listed:
147 The available machine configurations for Raspberrypi can be listed like this
153 To build an image for Raspberrypi3 64 bits, modify the file ``local.conf`` file
154 replacing the ``MACHINE ??=`` default value like this
160 To build the image we will target, it is also needed to add this to the file:
170 Everything is setup, time to build the image::
175 Overview of the build
178 Let's go through the build folders to understand what happened.
183 The folder location can be changed with the ``DL_DIR`` variable.
185 The Downloads folder is a fundamental part of the Yocto build environment,
188 builds do not waste time downloading the same files again.
194 This folder contains the final output artifacts that are ready for deployment.
196 bootloader files, and other components that are generated during the Yocto
200 - **images**: it contains the images that can be flashed or deployed to
201 the target device. Files like the Linux kernel, root filesystem (e.g., .
203 bootable images for the device are found here. t’s organized by the
204 machine (or target board) for which the image was built.
205 - **rmp/deb/ipk**: These folders contain the individual software packages
206 generated during the build, in the specified package format (RPM, DEB,
209 be installed on the target device using package management tools
212 The SDKs are generated when you use the ``bitbake -c populate_sdk``
219 divides the sysroot into individual components, which can be thought of as the
220 building blocks or packages that make up the entire sysroot environment.
223 into the sysroot. This approach allows for more efficient reuse of sysroots
225 management during the build process.
227 The sysroot-components directory helps optimize the build process because if
228 one package changes, Yocto only needs to update the corresponding component
229 rather than rebuilding or copying the entire sysroot.
231 If you followed the previous steps, here are the folders you will find:
233 - ``cortexa53``: Files for the Cortex-A53 (ARMv8-A) architecture.
234 - ``manifests``: Track files installed in the sysroot by package.
235 - ``raspberrypi3_64``: Files specific to the Raspberry Pi 3 (64-bit).
236 - ``x86_64``: Files for the x86_64 (PC) architecture, typically for
238 - ``x86_64-nativesdk``: Files related to the SDK for cross-compilation on
241 Each folder corresponds to components relevant to the specific architecture,
242 and they collectively form the complete environment needed to compile and run
243 software for the target and host systems.
248 The sysroots-uninative directory in Yocto is used to support the "uninative"
249 feature, which allows for more reproducible builds by ensuring that the build
251 provides a way to use the same native build tools across different Linux
257 The ``work`` folder in Yocto is a key directory in the ``tmp`` folder that
258 holds all the temporary build artifacts for each package during the build
259 process. It is where the actual building and compiling of individual packages
263 The ``work`` folder is typically structured by machine architecture and
277 This folder is very important and helps a lot during debug phases. The ``temp``
308 In this guide, we are on the ``scarthgap`` branch, so we are using lvgl 9.1.0.
310 Let's dive into this recipe to understand what is done. The objective is to add
311 this library as a shared object in the target rootfs, and also to generate a
314 This is the path of lvgl recipes: ``lvgl_yocto_guide/sources/meta-openembedded/
317 Here is the architecture of lvgl recipes folder:
334 - ``file`` folder contains all the patches that can be applied when
335 building the recipe.
338 - ``lvgl_9.1.0.bb`` is the recipe to build lvgl library.
341 For now let's understand the recipe of lvgl library.
379 **LICENSE**: Indicates the licensing of the software, stating that it is
380 distributed under the MIT License.
383 for the license file (here assumed to be LICENCE.txt). This helps to ensure the
384 integrity of the license file included in the package. In LVGL repository,
385 there is a LICENSE.txt. To get the value of the hash of the file, you can do
388 SRC_URI: Specifies the locations of the source code and patches for the recipe:
389 - The main source repository for LVGL specifying the master branch.
390 - The following arguments are the local patch files that will be applied to
391 the source code during the build process.
393 **SRCREV**: Defines the specific commit (in this case, a Git SHA hash) from
394 which the source code will be fetched. This ensures that the build uses a
395 consistent version of the code.
397 **inherit**: This line indicates that the recipe uses the ``cmake`` class,
401 **EXTRA_OECMAKE**: Additional options passed to CMake during the
404 **S**: This variable defines the source directory where the unpacked source
406 variable in BitBake that points to the working directory for the recipe.
409 specific to the LVGL library.
411 **FILES**: This is a BitBake variable used to specify the files that should
412 be included in a particular package. In this case, the variable is
421 lvgl`` to run all the tasks.
428 Fetch task fetches the package source from the local or remote repository.
430 The fetch Repo address has to be stored in **SRC_URI** variable. In
431 **SRCREV** Variable the commit hash of github repo is defined.
433 When the fetch task has been completed, you can find the fetched sources in
439 You can also find the folder architecture created in ``lvgl_yocto_guide/
441 only the fetch was done.
451 Unpack task unpacks the package that has been downloaded with Fetch task.
453 In the ``lvgl_yocto_guide/build/tmp/work/cortexa53-poky-linux/lvgl/9.1.0``
454 folder, you can now find the source code in ``git`` (as it was defined in
455 the recipe). You will also see the patches that will be applied on the next
456 step. So for now, the sources are unmodified and the same than the commit
466 Patch task locates the patch files and applies the patches to the sources
478 The Configuration task configures the source by enabling and disabling any
479 build-time and configuration options for the software being built before
485 the project, specifying build options and paths based on variables in your
486 recipe. It generates Makefiles or project files needed for the build. Also,
487 there are operations added in the task in ``lv-conf.inc``.
489 So at the end of the task, in the ``lvgl_yocto_guide/build/tmp/work/
491 generated running the CMake command, but nothing is built yet. Also, the
500 The Compilation task compiles the source code if any compilation steps are
508 Like in the previous task, this is handle by ``inherit cmake``.
510 In the build folder, you can now see the built library. The ``.so`` files
520 The Install task copies files that are to be packaged into the holding area
521 **${D}**. This task runs with the current working directory **${S}** which
522 is the compilation directory.
524 It creates the necessary directory for the header files in the destination
526 It installs the ``lv_conf.h`` header file from the source directory into the
527 appropriate include directory in the destination path, ensuring it has the
530 The lvgl library (``.so`` files) are also ready to be installed in the final
535 In the file ``build/conf/local.conf``, add these 2 lines at the end of the
543 This will add the lvgl library in the generated image, and it will also add
544 the library to the host SDK we will generate later on.
546 With these modifications, you can now run the image recipe again::
550 This will execute all the previous described tasks.
562 - **Development Environment**: The SDK provides developers with a
565 This includes the necessary tools, libraries, and headers to build
566 applications that run on the target device.
567 - **Cross-Compilation**: The SDK allows developers to cross-compile
571 - **Simplified Development**: By packaging all required components, the SDK
572 simplifies the process of setting up a development environment.
574 libraries; everything needed is included in the SDK.
575 - **Consistent Build Environment**: The SDK ensures that developers are
576 working with the same versions of and tools used in the Yocto
578 applications will behave as expected on the target device.
580 To generate an SDK of the environment, run the following command:
588 sh``. This script allows you to install the SDK where you prefer. Here is the
589 execution output of the script
597 You are about to install the SDK to "/opt/poky/sdk-with-lvgl". Proceed [Y/n]? y
599 If you want to ensure the SDK was generated with lvgl being installed, go to
600 the path you extracted the SDK and find all lvgl files:
607 The ``.so`` files you will find will depend on the LVGL configuration you used.
609 Now to use the SDK environment and cross-compile an application:
617 The tools available in LVGL library will depend on the build configuration
618 the recipe was done with.
625 recipes. The objective here is to create a recipe from scratch and to add the
626 generated binary in the image.
631 First, create a layer and add it to the configuration file
638 In the ``sources`` folder, a new folder was created: ``meta-mylvgl`` and the
639 directory tree should look like the following
655 Following this structure, create a folder containing the recipes to build 1
667 The content of ``recipes-lvglapp/lvgl-fbdev-benchmark/lvglbenchmarkfbdev_2.4.
677 # Update SRC_URI to point to the GitHub repository
695 The sources come from ``lv_port_linux`` repository. We apply 2 patches to modify the ``CMakeLists.t…
700 Create the first patch file
725 * - LV_STDLIB_CUSTOM: Implement the functions externally
748 /* The target buffer size for simple layer chunks. */
752 /* The stack size of the drawing thread.
761 /* Set the number of draw unit.
763 * > 1 means multiple threads will render the screen in parallel */
767 /* Use Arm-2D to accelerate the sw render */
783 /* Demonstrate the usage of encoder and keyboard */
832 Create the first patch file
888 Build the recipe
891 You should now be able to see the recipe listing the existing recipes
897 Now add the recipe to the project. Modify ``build/conf/local.conf`` file adding
904 Now build the image
910 Run this command to ensure the binary was generated and was installed in the