|Rebecca Chang 597c6800e2 Merge branch 'starfive-kirkstone-jan2023-external-release' into 'starfive-kirkstone'||3 months ago|
|conf||4 months ago|
|dynamic-layers||5 months ago|
|recipes-benchmark||7 months ago|
|recipes-bsp||3 months ago|
|recipes-core||4 months ago|
|recipes-devtools||4 months ago|
|recipes-extended||4 months ago|
|recipes-images||4 months ago|
|recipes-kernel||3 months ago|
|recipes-support||4 months ago|
|tools||4 months ago|
|wic||9 months ago|
|README.md||1 year ago|
|setup.sh||4 months ago|
The StarFive Dubhe Linux SDK is based on Yocto Project. It enables the creation of Linux distributions for any embedded project, as well as easy migration from a different architecture platform. The meta-starfive layer is built on top of meta-riscv to provide additional modifications such as Linux Kernel, and toolchains like GCC and LLVM.
Guide to use meta-starfive using Yocto
First, you need to download the essential Yocto dependencies, which can also be found on their official Yocto Guide:
$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd liblz4-tool
Next, you will need to install the
repo command from Google.
Now, we will be creating a workspace and retrieve the latest layers needed for our image creation.
$ mkdir starfive-yocto && cd starfive-yocto $ repo init -u https://github.com/starfive-tech/meta-starfive -b starfive-honister -m tools/manifests/starfive.xml $ repo sync $ repo start work --all
After having all the layers required, you can now source into the build environment by running the
setup.sh script in the meta-starfive layer. You should run the script in the starfive-yocto folder directory.
$ . ./meta-starfive/setup.sh
In meta-starfive, there is currently only one buildable machine that you can build for:
To build a initramfs image with QSPI-Image binary:
$ MACHINE=starfive-dubhe bitbake qspi-image
For the bitbake command, you can control the number of parallel tasks and the number of cores that Bitbake will use. You can either add the variables in the
<build_directory>/conf/local.conf file, or add it in your shell environment command, for example:
$ PARALLEL_MAKE="-j 6" BB_NUMBER_THREADS=4 MACHINE=starfive-dubhe bitbake qspi-image
To populate the extensible eSDK shell script, you can use the
-c populate_sdk_ext command:
$ MACHINE=starfive-dubhe bitbake qspi-image -c populate_sdk_ext
NOTE: For your first build, it may take several hours to build the image.
Run the 64-bit machine in QEMU using the following command:
MACHINE=starfive-dubhe runqemu nographic dubhe-image-initramfs
Tip: Once QEMU starts, in nographic mode, the terminal is ‘controlled’ by the Linux console. Thus, to kill QEMU and get back to the terminal, you can:
CTRL-a xto kill QEMU and exit
You will find image components such as openSBI (fwpayload.bin) and the Linux kernel in the bitbake build directory (/build/tmp-glibc/deploy/images/starfive-dubhe/_) after your bitbake process is done. You can also find the full QSPI binary image generated (QSPI-Image.bin), which includes the boot codes, openSBI and kernel in a single binary.
You can flash the QSPI binary into the FPGA via openOCD or other FPGA flashing tools.
To modify the kernel, you can use the devtool command line:
$ MACHINE=starfive-dubhe devtool modify virtual/kernel
The devtool command will fetch the source code and unpack them in the _‘build/workspace/sources/‘_ directory.
Now you can make your changes in your source code in the workspace directory.
After you had done your changes, you can build only the kernel by:
$ MACHINE=starfive-dubhe devtool build <kernel_name> or $ MACHINE=starfive-dubhe bitbake virtual/kernel
You can obtain the image generated in the images folder _build/tmp-glibc/deploy/images/starfive-dubhe/_
Once you are happy with the changes, you can go to the source folder and commit your changes:
$ git status
$ git add .
$ git commit -m "Changes added"
$ devtool finish <kernel_name> <layer_path>
To rebuild your image, the steps include:
$ MACHINE=starfive-dubhe bitbake qspi-image
Rebuilding will take less time as the sstate-cache is saved during your first build.
In case you accidentally deleted files in the build/tmp/deploy/images/ directory and some of the files are not automatically re-created when you build the image again, you can rebuild and recreate the kernel files by:
$ MACHINE=starfive-dubhe bitbake -c clean virtual/kernel $ MACHINE=starfive-dubhe bitbake virtual/kernel