Hongmeng LiteOS source code reading tutorial + adding a system call to LiteOS

1. Hongmeng Liteos source code reading tutorial

Hongmeng's source code is placed in the openharmony folder, and the kernel folder under openharmony stores the relevant code and implementation of the operating system kernel.

The kernel is the core part of the operating system, so the source code responsible for: resource management, task scheduling, memory management, device drivers, and process communication can all be seen in the kernel folder.

After entering the kernel folder, you will see liteos_a and liteos_m. We only need to know that liteos_a is for embedded devices, so the development board used in our experiment is to look at the code under liteos_a, while liteos_m is designed for Internet of Things devices. , so let’s not look at this for now.

Friendly reminder: The Ubuntu virtual machine has a visual interface. You only need to click on the desktop to enter Files to see the files in the system:

After entering liteos_a, the real core code is also stored under the kernel:

Mainly introduce 3 more important ones:

base: This folder contains the basic parts of the operating system kernel, such as the scheduler, synchronization mechanism, memory management and other basic functions.

include: This folder contains all header files required by the kernel.

user: This folder contains some user-level functions, such as user tasks, user interface, etc.

So if you want to view the code related to the kernel, go to the base folder, and if you want to view or modify the header files, go to the include folder.

Assume we now enter the base folder:

Next, I will give you a brief introduction one by one:

core: Contains the core code of the kernel, such as initialization code, startup code, etc.

include: Contains all header files in the base part.

ipc: is the abbreviation of inter-process communication, which is related to the process and contains the code to implement inter-process communication.

Mem: is the abbreviation of memory, which contains the code to implement memory management, such as memory allocation, memory release, etc.

misc: Contains miscellaneous code, such as tool functions and debugging functions.

mp: Contains multi-processor related code, such as multi-core scheduling, synchronization, etc.

om: Contains LiteOS operation and maintenance related code.

sched: is the abbreviation of scheduling, which contains the task scheduling code of LiteOS, including task creation, deletion, switching, etc.

vm: is the abbreviation of virtual memory, which contains the code to implement virtual memory management, such as page table management, address translation, etc.

2. Add a system call to LiteOS

Experimental requirements:

This experiment needs to complete two parts in user mode and kernel mode respectively:

Content 1: In user mode, corresponding library functions should be added as interfaces for newly added system calls.

Content 2: Add the system call corresponding to the interface function in the kernel mode.

Write an application that triggers the newly added system call by calling the library function interface added in the first step, thereby verifying the correctness of the newly added system call.

References:

Learning OpenHarmony LiteOS-A Kernel Documentation--System Call-Open Source Basic Software Community-51CTO.COM

 Step 1: Add the system call number in the kernel mode:

Open the /home/book/openharmony/prebuits/lite/sysroot/usr/include/arm-liteos/bits/syscall.h file and add the following code:

#define __NR_hxsyscall   (__NR_OHOS_BEGIN +21)

Add the following code at the end of the same file:

#define SYS_hxsyscall    (__NR_OHOS_BEGIN + 21)

Explanation:Define a call called __NR_hxsyscall and SYS_hxsyscall macro, its value is (__NR_OHOS_BEGIN + 21) The system call number of the system call is customized. After defining the macro in this way, you can use __NR_hxsyscall or SYS_hxsyscall in the code to represent a custom system call number to facilitate subsequent calls to the system call in the code.

The two macros are actually equivalent, but provide different naming options. Developers can choose to use SYS_hxsyscall or __NR_hxsyscall as needed.

If it is in user space (user mode) code, the unprefixed version may be used, while in the kernel (kernel mode) code, the prefixed version may be used, but this completely depends on the specific coding style and conventions of the project. .

Step 2: Add the system call number in user mode:

In the /openharmony/third_party/musl/kernel/obj/include/bits/syscall.h file, add the following code:

#define __NR_hxsyscall    (__NR_OHOS_BEGIN + 21)

Explanation: /openharmony/third_party/musl/kernel/obj/include/bits/syscall.h file is located in the kernel code of the musl libc library and runs in user mode.

The /home/book/openharmony/prebuits/lite/sysroot/usr/include/arm-liteos/bits/syscall.h file is located in the system header file of the OhOS Lite operating system and runs in the kernel state.

So the first step is to add the system call number in the kernel mode, and the second step is to add the system call number in the user mode.

Step 3: Add function definition and implementation

Enter home/book/openharmony/kernel/liteos_a/syscall/los_syscall.h and add the declaration of the system call function:

Add a .c file to the directory at the same level as syscall to write the content of the system call function:

Implement system call function:

Step 4: Implement the mapping relationship between the calling number and the calling function

Open the /home/book/openharmony/kernel/liteos_a/syscall/syscall_lookup.h file and add the mapping relationship between system call numbers and system call functions:

Mapping the user-mode system call macro __NR_hxsyscall and the system call function HxSyscall is equivalent to an association.

Step 5: Write the test function

Create the hxsyscall folder under /home/book/doc_and_source_for_openharmony/apps, and then create the Makefile and hxsyscall.c files (you can directly copy the contents of hello for modification):

Modify the content of hxsyscall.c, call the user mode system call macro, and pass in the parameters:

Note: Because the SYS_hxsyscall macro has been associated with the HxSyscall system call function, "wake up" will be passed as a parameter to the HxSyscall function in the figure below, and finally Hx call you to wake up!

Then modify the contents of the Makefile:

Open a terminal in the same directory and enter make to compile:

Step 6: Recompile the kernel

This step is critical, because a new system call number has been added, and the kernel must be recompiled to make the call number take effect and associate it with the system call function.

First delete the following files in /openharmony/kernel/liteos_a/out/imx6ull:

Go to /openharmony/kernel/liteos_a and then enter the command bar. First enter the next two lines of code to ensure that the operation is foolproof:

cd  /home/book/openharmony/kernel/liteos_a
cp  tools/build/config/debug/imx6ull_clang.config .config  

Then enter make clean:

Then enter make -j 8:

Then enter make rootfs to compile the root file system:

Rename rootfs.img under out/imx6ull to rootfs.jffs2:

cp out/imx6ull/rootfs.img out/imx6ull/rootfs.jffs2

Step 7: Development board running

Manually copy the hysyscall file under hxsyscall under apps to the home/openharmony/kernel/liteos_a/out/imx6ull/rootfs/bin directory and recreate rootfs.jfss2

Open the terminal under openharmony/kernel/liteos_a/out/imx6ull and enter mkfs.jffs2 -s 0x10000 -e 0x10000 -d rootfs -o rootfs.jffs2

This command creates a JFFS2 file system image with a page size and an erase block size of 64KB, including all the contents in the rootfs directory, and saves the image as < /span>rootfs.jffs2 file. This image can then be burned into flash memory to provide an initial file system for the embedded device.

Back to the computer, first delete the existing liteos.bin and rootfs.jffs2 files in the /doc_and_source_for_openharmony_imx6ull/IMX6ULL/development board supporting information/software/programming tool/100ask_files_imx6ull programming tool/file folder.

Then copy the new liteos.bin and rootfs.jffs2 to the folder:

First connect the development board, then open MobaXterm and connect to the serial port, then click download to memory and start.

Start the development board according to the first test, and 81000000 appears. Enter cd ./bin, then enter ls. You can see that the file is consistent with the file in the virtual machine:

Enter ./hxsyscall and the output shows Hx call you to wake up!

Guess you like

Origin blog.csdn.net/RuanFun/article/details/134444501