Preliminary Study on L4 F9 Kernel Microkernel

F9 Kernel is an experimental microkernel implementation. It is inspired by the famous L4 microkernel to build flexible embedded systems. The motivation for the development of the F9 microkernel is to use the latest kernel design ideas to run real-time and time-sharing applications (such as wireless communication applications, etc.) on the ARM Cortex-M series of microprocessors, while taking into account efficiency (performance + power consumption) and safety Performance (memory protection + isolated execution). It has the following characteristics

F9 follows the basic principles of the microkernel. It only implements the address space, thread management and IPC communication mechanism in the processor privilege mode.
Designed and customized for the ARM Cortex-M series, supporting NVIC (nested vector interrupt controller), bit band, MPU (memory protection unit).
The efficient scheduling and tickless mechanism allows the ARM Cortex-M to wake up only when needed, whether it is at a predetermined time or an interrupt event. Therefore, it produces better energy savings than the usual method of using the system timer SysTick, which requires a constantly running high-frequency clock.
Support KProbes mechanism, KProbes is a dynamic detection system inspired by the Linux kernel, which allows developers to collect additional information about kernel operations without recompiling or restarting the kernel. It allows the code to be inserted into the position in the kernel. When the ARM core encounters a detection point, the inserted code will run. Once the instrumented code is executed, the kernel will continue to execute normally.
Each thread has its own TCB (Thread Control Block) and is addressed by its global id. The dispatcher is responsible for switching context. Threads with the same priority are executed in a round-robin fashion.
There are three ways of memory management
1. Memory pool, which represents an area of physical address space with specific attributes.
2. Flexible page (Flexible page), which describes an area of the address space that is always aligned in size. Unlike other L4 implementations, the flexible page in F9 replaces the MPU area.
3. Address space is composed of these flexible pages.
Provide system calls to manage the address space
1. Grant: Grant memory pages to new users and can no longer be used by former users.
2. Map: This implements shared memory-memory pages are passed to another task, but both tasks can be used.
3. Flush: Memory pages that have been mapped to other users will be flushed from their address space.
Regarding the interaction between user threads and microkernels, the concept of UTCB (User Level Thread Control Block) is being adopted. UTCB is a thread-specific small area in the thread virtual address space, and it is always mapped. Therefore, access to UTCB will never cause a page fault, which allows the kernel to have good access to system call parameters, especially IPC payloads copied from/to the user thread.
The kernel provides synchronous IPC (inter-process communication). The short IPC only carries the payload in the CPU register, while the complete IPC replicates the message payload through the UTCBs of the communicating parties.
Support kernel debugging and analysis mechanism:
1. Configurable debug console
2. Memory dump
3. Thread analysis: name, uptime, allocated/current/used stack
4. Memory analysis: kernel table, pool free/allocated size, fragmentation

Development board:

The development platform used in this environment is STM32F407G-DISC1, which is the stm32f4-discovery series, the main control is Cortex-M4F core, and the onboard st-link debugger is supported. The development board resources are as follows:

STM32F407VGT6 in LQFP100 package
ARM® 32-bit Cortex® -M4 CPU with FPU
168 MHz max CPU frequency
1 MB Flash
192+4 KB SRAM including 64-Kbyte of core coupled memory
GPIO with external interrupt capability
3x12-bit ADC with 24 channels
2x12-bit D/A converters
USART/UART (6)
．．．．．．

STM32F4DISCOVERY Discovery has 6 UARTs. The default configuration is 115200 8N1. It should be noted that ST-Link Virtual Com Port is not wired to chip serial port. In order to enable console output you should use a serial pins cable and connect it to UART.

Burning instructions, STM32F4DISCOVERY Discovery has an ST-LINK/V2 debugger onboard, which can work with OPENOCD to realize bare metal burning.

Get the kernel:

　The f9 kernel is hosted on github in accordance with the BSD open source agreement, the kernel is not big, and the download can be completed by a simple git clone command.

git clone https://github.com/f9micro/f9-kernel.git

Configure the kernel:

The build environment dependency of f9 kernel is the same as that of linux, both are mconf. If the PC has built a linux development environment before, you can directly develop it, otherwise, install the dependency according to the linux development standard.

Execute make config to call out the menuconfig configuration interface similar to linux:

The platform chooses STM32F4, and the default serial port (usart4) is used, that is, the onboard PA0 and PA1 PIN pins. The mapping relationship between the serial port and the pin is:

Compile the kernel:

After the configuration is complete, click Save Configuration before exiting the configuration menu. After exiting, execute the make command directly under the console to compile the kernel:

Execute make clean to clear the compilation intermediate files and compilation results

If you want to explore the compilation details of each file, you can execute make V=1

According to the output details of the above figure, it can be seen that the output targets include f9.elf, f9.elf.bin and f9.bin, among which f9.bin and f9.elf.bin are exactly the same, and both correspond to f9.elf binary file.

Burn the kernel:

The development board supports the USB simulation disk burning method. After the system is started, the platform will simulate a disk on the PC side. At this time, the compilation result file f9.bin can be copied to the virtual disk. The disk itself is virtual, and the copy process is actually During the burning process, after the copying is over, restart to start burning the firmware. In addition, Zephyr's west environment has a corresponding burning tool, which should also support burning f9 kernel. You can try it later. Here, first use the first disk burning method:

Copy the kernel to the virtual disk to complete the burning:

Connect the USB2TTL serial cable to USART4 (PA0, PA1), and use minicom to observe the kernel output during startup.

Use st-flash to burn the kernel:

Burning:

st-flash write f9.bin 0x8000000

Read:

st-flash read firmware.bin 0x8000000 0x1000

Erase:

st-flash erase

Burning and debugging based on zephyr environment:

We want to use the zephyr environment to burn and debug the f9 kernel, let's take a look at how zephyr plays this development board:

The first step: Install the zephyr development environment according to the official zephyr documentation, including installing west, cmake, sdk tools, requirements.txt dependencies and downloading the code.

Step 2: You need to install elftools, otherwise an error will be reported when compiling the DISCO1 development board project. I don't know why the requirements.txt does not list the installation, execute pip3 install pyelftools.

Step 3: Compile:

First execute west build -t clean to clear the last compilation result file

Then execute west build -b stm32f4_disco samples/basic/blinky to compile the blinky project, as shown below:

Step 4: Burning

Zephyr burning does not rely on the virtual disk mechanism used above, but is based on ocd and stlink.

Connect the USB port and execute west flash

Observe the printed information and notice that the serial port used by zephyr is different from the f9 kernel. Zephyr uses the serial port usart2, which is PA2/PA3.