.png){kind=small}
Introduction
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 upstreamed.
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 hardknott
version:
The structure of a meta-nezha is divided into two main parts:
-
meta-nezha-bsp- this layer contains recipes forboot0,u-boot,OpenSBIandlinux 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 andwksfile which is used to create image file which can be flashed to the SD card.
This layer was split 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 boot0 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 U-Boot for
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 U-Boot on OpenSBI during the
compilation task. The tftp-mmc-boot.txt script which is used by U-Boot
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
autofs4 and cgroups. Enabling these options was necessary because, without
them, kernel can not be booted which is signaled with the following error:
|
|
System structure
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 u-boot etc.
In meta-nezha you can find a formal description of the structure in
nezha.wks
file.
Note: More information about it you can find here.
Nezha Yocto system startup
So it really works!
Known issues
rng-tools
This package contains many tools. One of them is Random Numbers Generator
daemon - 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 SIGSEGV in libc-2.33.so:
|
|
This problem doesn’t exist when the haveged random number generator is used in
the build.
Summary
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
