Testing Background

The Raspberry Pi 4 is a very popular maker computer in the Chipmaker community, setting a new benchmark for single-board computers worldwide. As the latest generation product of Raspberry Pi, it benefits from a processor chip with four Cortex A72 architecture computing cores, with a main frequency of up to 1.5GHz, providing performance comparable to that of everyday office computers.

In recent years, with the development of the Internet of Things industry, many excellent IoT operating systems (IoT OS) have emerged. These IoT OS kernels are based on Linux, VxWorks, RTOS, etc. Common RTOS include uCOS, ChibiOS, FreeRTOS, and RT-Thread. Today, we will use the small and beautiful RT-Thread (abbreviated as RTT) to test the Raspberry Pi 4. It is developed independently by Chinese developers and is currently the most widely used open-source RTOS in China.

RTT recently provided board-level support for Raspberry Pi 4, and we can find the branch for Raspberry Pi 4 in the SBC directory of the RTT source code. Through the RTT system, the Raspberry Pi can perform benchmarking tests with other mainstream Cortex-M core microcontrollers under the same system, which is quite interesting. Hence, we have today’s evaluation.

Considering that some time-sensitive players may not have time to read the entire text, we will report the important content first. To get straight to the point, the test score for Raspberry Pi 4 is 3.772 DMIPS/MHz. This computation speed has reached an industry-leading level. That’s all for now ^_^

Just kidding, everyone, we are done.

Setting Up the Compilation Environment

The RTT system for Raspberry Pi uses RT-Studio as the IDE on Windows, and the compilation environment is achieved through the ENV tool, which integrates the ARM GCC compiler. Of course, you can also customize and minimize the setup of this compilation environment like I did.

I first installed the ENV tool. Did you notice the blue underlined hyperlink symbol on the “ENV tool”? You can click on it to download it. After downloading the ENV tool, unzip it to your preferred path.

Next, install the gcc tool in the compilation tools directory under the env folder. I used gcc-arm-8.3-2019.03-i686-mingw32-aarch64-elf. Did you see the hyperlink symbol on the “gcc tool”? You can click on it to download it as well.

Then, extract gcc-arm-8.3-2019.03-i686-mingw32-aarch64-elf and place it in the tools directory of env. The completed path should look like this (I intentionally omitted the drive letter and the parent directory of env in the description, as some students may place it in the program files directory, while others may place it directly in the root directory):

env/tools/gnu_gcc/arm_gcc/gcc-arm-8.3-2019.03-i686-mingw32-aarch64-elf

Finally, download the source code of RTT with the following command:

git clone https://github.com/RT-Thread/rt-thread.git

After downloading the RTT source code, navigate to the rt-thread/bsp/raspberry-pi/raspi4-64 path, modify the rtconfig.py file by changing the value of EXEC_PATH to point to the bin directory under gcc-arm-8.3-2019.03-i686-mingw32-aarch64-elf. Then, in the current path (raspi4-64), open env and enter scons.

If you find that after entering scons, the compilation error message appears as follows, it indicates that the environment has been set up successfully. As for how to resolve this error, we will fill in the details later.

Don’t go away; the next section will teach you the repair methods.

Fixing scons Compilation Errors

If you followed the readme tutorial in the RTT source code step by step and got stuck at the scons step, then my tutorial in this section can help you.

The scons error principle is very simple; it is related to the source code being compiled by other projects.

The solution is straightforward: we just need to execute a cleanup first.

Cleanup command:

scons -c

Then, you can normally use scons to compile.

Here is a screenshot of the resolution process:

After the compilation is complete, an rtthread.bin file will be generated in the raspi4-64 directory. Place it in the boot directory of the Raspberry Pi system’s TF card and modify the contents of config.txt in the boot directory as follows:

enable_uart=1arm_64bit=1kernel=rtthread.bincore_freq=250

The above config.txt file sets up serial debugging and the kernel file, and sets the main frequency to 250MHz. Players who know what they’re doing can set the main frequency even higher.

Using Serial Debugging on Raspberry Pi 4

Connect the debugging serial port of the Raspberry Pi to the serial debugging line. Note that the 5V interface does not need to be connected; we only use GND, TX, and RX.

After ensuring the TF card is properly inserted, first insert the USB-to-serial module into the computer, start the serial debugging tool, and then power on the Raspberry Pi. Note that powering on the Raspberry Pi should be the last step; do not reverse the order. You should be able to see the startup print output in the serial debugging assistant as shown in the image below. My RTT system is newly compiled, so the compilation date is today, January 20th. The serial debugging print is as follows:

Adding Dhrystone Software to the RTT System

Next, let’s return to the RTT system compilation environment and recreate a system with performance benchmarking software.

In the previous env environment, enter menuconfig and press enter to enter the RTT kernel settings. In the online packages under tools packages, find DHRYSTONE and check it by pressing the space bar, as shown in the image below.

Dhrystone is one of the most common benchmark programs for measuring processor computing power, often used for measuring integer operation performance of processors. The program is written in C language, so the compilation efficiency of the C compiler also greatly affects the test results. Therefore, we must consider the compiler version and optimization level during testing and avoid comparing programs with different optimization levels.

Additionally, the other CoreMark in the above image is also a benchmarking software, but I had some issues with testing it, so let’s not discuss that for now.

The compiler settings file is in rtconfig.py, and the gcc version used this time is 8.3, as shown in the image below:

The default optimization level is O2, as shown in the image below. We will first use this default optimization level to compile Dhrystone, and in the next section, we will perform tests with O0 level optimization.

Dhrystone belongs to the online package and is not integrated into the default source code. After completing menuconfig, you also need to use the command pkgs update to download the Dhrystone source code, as shown in the image below. This step is very important; don’t forget to download it, or you will waste compilation time for nothing.

Use the scones command to compile a new rtthread.bin and place it in the boot directory of the Raspberry Pi to replace the old one. After this boot, you can use the help command to view the available commands and find dhrystone_test, as shown in the image below:

Let’s run it and see; the default parameter is to loop 320000 times, as shown in the image below:

Because the speed is too fast, there was no time to time it, so the test failed, as shown in the image below:

Therefore, next, we need to go back and modify the settings parameters in menuconfig to increase the loop count by two zeros…