As it was mentioned in first post We are interested in support for this board in Yocto Project, and this post will show you what we have achieved in this field.
Previous blog post made a lot of noise and was appreciated by people from RISC-V International. Now it is also available on their site.
Whole code of the meta layer you can find at github.
It should be mentioned that
meta-nezha is really early support so
the recipe’s code isn’t that clear and for now, it isn’t prepared to be
Nezha D1 meta layer
First of all, it is important to say what exactly the Yocto Project and it’s meta layers are. Yocto is a project which is hosted by the Linux Foundation and gives you templates, methods, and set of interoperable tools for creating OS images for embedded Linux systems. Secondly, the Yocto project is used by many mainstream embedded Linux providers and offers thousands of packages that are available through layers. What are they?
Yocto project can be used by itself or be extended by meta layers, which are repositories with instructions (recipes) telling the build system what it should do. By separating the instructions into layers, we can reuse them and share for other users. Thirdly, with Yocto Project you can bring to life exactly the Linux you want and need. The project lets you choose your CPU architecture, select footprint size, and remove and/or add components to get the features you want.
Construction of meta-nezha
Nezha D1 layer is using the following Yocto Project meta layers in
The structure of a
meta-nezha is divided into two main parts:
meta-nezha-bsp- this layer contains recipes for
linux kernel. It also contains machine configuration which set/unset or enable/disable the key features of the board,
meta-nezha-distro- contain a recipe for the minimal image, configuration of the system eg. what init manager is used and
wksfile which is used to create image file which can be flashed to the SD card.
This layer was splitted because it is nice to separate the Board Support Package (BSP) from application layer. BSP layer is a collection of information that defines how to support a particular hardware device, set of devices, or hardware platform.
Key repositories used by
meta-nezha-bsp recipes are forks of repositories
patched / created by smaeul:
Note: It was decided to fork the
smaeulrepositories because the original repos are often updated and rebased to the newest branches from upstream repositories and it often caused problems with the proper build of the yocto image.
Main work to do was to adopt the bootflow of Nezha to the Yocto Project which
was described in previous
blog post. In this process, the
boot0 recipe was created from the ground.
That wasn’t so smooth to integrate its compilation flow with the Yocto build
engine due to missing some headers in
workdir. So the patch for
Makefile was provided also and it is applied during the building process.
It wasn’t enough because a lot of work had to be done to compile
the D1 chip.
u-boot-nezha recipe contains procedures of creating the TOC1
image from binaries described in
toc.cfg. This configuration file contains
information about which files are included in TOC1 image and address of a memory
where they should be loaded. Creating the TOC image is different than others
because this image contains three binaries which one is from
OpenSBI. So it
was necessary to add a dependency for
OpenSBI during the
compilation task. The
tftp-mmc-boot.txt script which is used by
during boot to set up environment variables was also modified to provide
bootargs specific for the Nezha.
The situation with Linux kernel recipe isn’t different. Due to the “work in
progress” status of the support for D1 chip in Linux kernel, We decided to
create a separate recipe of the kernel for the Nezha board. It provides to the
building system two configuration files with kernel options that enable
cgroups. Enabling these options was necessary because, without
them, kernel can not be booted which is signaled with the following error:
Below image shows the SD card structure after flashing the image:
As you can see the
boot0 SPL and
u-boot.toc1 image are in an area of raw
disk space which means it isn’t a partition. After boot, the program is loaded
from ROM and this program reads SC card to find the
boot0 first, and then the
boot0 load the
u-boot.toc1 which start the
meta-nezha you can find a formal description of the structure in
Note: More information about it you can find here.
Nezha Yocto system startup
So it really works!
This package contains many tools. One of them is Random Numbers Generator
rngd. This daemon feeds data from a random number generator to the
kernel’s random number entropy pool, after first checking the data to ensure
that it is properly random.
For some reason it crushes during start with
This problem doesn’t exist when the
haveged random number generator is used in
If you think we can help in improving the security of your firmware or you
looking for someone who can boost your product by leveraging advanced features
of a used hardware platform, feel free to book a call with us
or drop us email to
contact<at>3mdeb<dot>com. If you are interested in similar
content feel free to sign up to our newsletter