In view of the increasing number of users porting Linux to the Andes Embedded platform (AndesCore N12 or N10), the purpose of this article is to help users quickly and efficiently port Linux to self-built FPGA boards (CPU It is N12 or N10 of AndesCore). The author has assisted engineers from many companies in the work of transplanting Linux to Andes platform, and explained the problems and blind spots that are easy to encounter in the Linux transplantation process. I hope to be helpful to the users, and I hope the readers will not hesitate to advise and provide your valuable opinions. .
When porting Linux, you will find that the user's Andes platform may have various combinations. In addition to the CPU using N12 or N10, the user has other peripherals (such as RAM, ROM, Timer...) Each has its own advantages. In order to systematically explain the essentials of Linux transplantation, a clear hardware, software, and development tool (toolchain) environment will be selected for exercise and explanation. In addition to allowing readers to implement the narrative in the text, when When the user’s peripheral hardware is not originally designed (the user’s own IP), the basic principles of porting can be used to change the Linux driver that wishes to port the IP, and the other source code remains unchanged, and the user’s peripheral driver is ported to Andes' platform.
In the process of Linux transplantation, users must establish a basic concept, that is, the entire Linux OS can be divided into two parts. The first part is the HW dependence code related to the hardware. This part of the program code will cause the software to correspond to different hardware. Some parts need to be rewritten to varying degrees; the second part is generic code that has nothing to do with hardware, this part of the program code has nothing to do with hardware, pure software operation, and will not change due to platform (Andes, X86, Arm..) changes difference. The first step for the engineer who transplants Linux needs to be able to distinguish which part of the program code is HW dependence code, and the other part of the program code is generic code. If the program code is judged incorrectly (HW dependence code/generic code) at this stage, it will delay Linux migration. The process and increase the difficulty of debugging.
In the process of porting Linux to the Andes platform, the Linux infrastructure must first be successfully ported. When debugging, the basic architecture components of Linux are CPU, Timer, interrupt and UART. When the CPU and these 3 peripherals are successfully transplanted, the scheduler can run, and printk can also run. The Linux system can already operate normally. The next work only needs to transplant the drivers that need to be transplanted one by one. After the basic skeleton is transplanted, printk is also available for debugging, and then just fill in the meat (device drivers that need to be added). The more difficult part of Linux transplantation is that the debugging before the Linux infrastructure has not been completed (the initial stage of Linux transplantation). Fortunately, the standard debugging tools provided by AndeShape and AndeShape's debugger AICE can identify the problem step by step and allow the initial transplantation. Linux debugging has also become very simple, and the specific method will be explained in detail later. This article focuses on how to build a Linux infrastructure on the Andes platform. As for the porting of individual Linux drivers, there are many books in the market, so I won’t go into details in this article.
1. Development environment and proceduresUsers start to port Linux to the Andes platform. First, they must first select a version of Andes Linux source code as a benchmark before performing software migration, modify the source code to meet the user’s development platform, and go through the compile and link of the tool chain. The generated Linux image file is then placed on the FPGA board to verify that the program is written correctly, and the program is developed accordingly: software writing-"FPGA board verification, and then back to the software writing program until all peripheral IPs are verified on the FPGA board Completely, Linux transplantation is completed. As shown in Figure 1, during Linux transplantation, AICE debugging can effectively accelerate the speed of Linux transplantation.
Chart 1 The development process of Linux transplantation
This article selects a set of Linux source code, tool chain, FPGA board and netlist as the platform of Andes (described in 1.1, 1.2, 1.3) for Linux transplantation. Readers can compare their own platform with Andes' platform to effectively shorten the product development process.
1.1 Andes version of Linux source code
At present, the latest version of Andes Linux source code is in AndeSoft's BSP310. The location of the Linux source code in the BSP310 suite is: BSPv310/source/Linux/linux-2.6.tgz. Use the ramdisk "xc5_glibc_ramdisk.img" in BSP310 as the filesystem.
1.2 Tool chain
The tool chain chosen for this Andes platform is AndeSoftâ„¢'s nds32le-linux-glibc-v2.
1.3 FPGA board and netlist
The FPGA board is AndeShape's XC5 development board. Netlist is the N10 producTIon version of AndesCore.
The transplantation platform refers to the platform on which the user wants to transplant Linux, that is, the target platform for transplanting Linux. The comparison list of the transplantation platform and the Andes platform is as follows: (The software listed in it all belong to the package in the BSP310).
Porting platform
Andes platform
Description
Linux source code
linux-2.6.tgz
linux-2.6.tgz
Users should develop from the source code of the Andes version
Tool chain
nds32le-linux-glibc-v2
nds32le-linux-glibc-v2
If users use the new version of AndesCoreâ„¢, they can change to a new corresponding tool chain
FPGA board
User design
XC5
Netlist
User-generated
N10 producTIon version
Chart 2 Comparison table of platform and Andes platform
2. Boot loaderIf users have their own custom boot loader, they can use the custom boot loader to speed up the development time. If there is no boot loader development experience, you can choose u-boot as the system boot loader. The location of the source ocde of u-boot is BSPv310/source/Standalone/u-boot/u-boot.tgz.
2.1 U-boot
The u-boot source code in AndeSoftâ„¢ BSP310 is the u-boot version that needs to be executed after EBIOS boot up. The U-boot version (ROM version) that directly boots up without the assistance of other software is more in line with the needs of users. For the usage of Andes version of u-boot, please refer to the BSP310 User Manual. If you want ROM version of u-boot, you need to patch the u-boot software in BSP310, the instructions are as follows:
# patch -p1 ï® patching file arch/nds32/cpu/n1213/ag101/cpu.c
ï® patching file arch/nds32/cpu/n1213/start.S
ï® patching file arch/nds32/include/asm/u-boot-nds32.h
ï® patching file arch/nds32/lib/board.c
ï® patching file board/AndesTech/adp-ag101p/config.mk
ï® patching file include/configs/adp-ag101p.h
The u-boot source code completed by the patch can generate a ROM version of the u-boot image. The execution result after booting directly is shown in Figure 3.
Chart 3 u-boot execution result chart
3. Debugging environmentBefore porting Linux to the Andes platform, it is necessary to set up a debugging environment, especially for the porting of the underlying Linux source code, which is of great help. Before printk is not operating normally, it needs to rely on AndeShape's AICE and AndeSoft's GDB for debugging.
3.1 Set Linux kernel debugging options
Linux Kernel needs to set some debugging options in order to smoothly use AndeSoft's GDB for debugging. The Linux kernel debugging options on the Andes platform are set as shown in Figure 4. Adding these options will increase the space of the kernel image file. If the space is too large to meet the design requirements, you can turn off the debugging options after the debugging is completed. To save unnecessary space waste.
Figure 4 Set Kernel hacking to check the debugging option
3.2 Linux kernel debugging program
After building into kernel bootpImage (including kernel debug message as shown in the four options in the diagram), the Linux image file is placed on the FPGA board, and the AndeSoft GDB on the PC host side is connected to the FPGA board through the network (socket) and AICE for debugging.
3.2.1. Compile the chain into an image file
After setting AndeSoft's cross-compiler path, use the following command to get bootpImage through the compiler and linker, the command is as follows:
#CROSS_COMPILE=“nds32le-linux-†ARCH=“nds32†make xc5_defconfig
#CROSS_COMPILE=“nds32le-linux-†ARCH=“nds32†make menuconfig
# CROSS_COMPILE=“nds32le-linux-†ARCH=“nds32†make bootpImage INITRD=xc5_glibc_ramdisk.img
Put the generated bootpIamge on the FPGA board, connect AICE to the FPGA board to start ICEman, the instruction is as follows:
#C:AndestechAndeSight200MCUice》ICEman.exe --p 1234
The AndeSoftâ„¢ GDB on the PC host is connected to the FPGA board through the network (socket) and AICE for debugging. The demonstration commands are as follows:
#ddd --debugger nds32le-linux-gdb vmlinux
gdb》target remote 10.0.2.164:1234
The IP value 10.0.2.164 is an application example, and the user can set it according to the actual IP value of the environment. After the environment setting is completed, you can start the debugging project.
4. Key points of experience in porting Linux to Andes platform4.1 Kernel loader debugging implementation
The purpose of the kernel loader is to decompress the kernel main program and load it to the correct location. This program and the kernel main program are two different programs, but they will be packaged in zImage together, but the kernel loader will be attached in front of the zImage. When debugging, ELF files with different files are needed to perform correct debugging. The location of the kernel loader is arch/nds32/boot/compressed/vmlinux, and the instructions are as follows.
#ddd --debugger nds32le-linux-gdb arch/nds32/boot/compressed/vmlinux
The ELF file "vmlinux" of the kernel main program is commanded in the root directory of the kernel source code as shown below.
#ddd --debugger nds32le-linux-gdb vmlinux
4.2 Linux kernel debugging implementation
After the kernel loader is executed, it will jump to the kernel main program for execution. The entry point is the main function "start_kernel" of the kernel after the assembly code of arch/nds32/kernel/head.S is executed.
4.2.1. RAM offset patch
Andes version of Linux source code with XC5 platform, the starting position of RAM (referring to PA) is 0x0, if the starting position of RAM of user FPGA development board is not 0x0, the starting position of RAM in FPGA board must be modified. The method is to perform RAM address patch in the Andes version of the Linux source code, and adjust the RAM location in the source code to the real location of the RAM in the FPGA development board.
4.2.2. PA/VA remap table
When the PA setting of the FPGA board IO is correct, the user needs to set the PA/VA remap table, the method can refer to arch/nds32/include/asm/spec-ag101.h, according to the PA/VA correspondence in apec-ag101.h To increase or decrease the PA/VA remap table of the user’s own IO device.
4.2.3. Kernel decompression and software breakpoint
During kernel debugging, if debugging is performed at a low address, such as head.S, when the software breakpoint is set, the breakpoint cannot be stopped and the AICE is disconnected. The reason is that when the user sets the software breakpoint, the instrucTIon at the breakpoint will be modified and added to the break instruction. However, when the kernel is decompressed, the code of the debugged program will be overwritten, causing inconsistency with GDB debugging and causing errors. The solution is to change the original setting of software breakpoint to hardware breakpoint, so that debugging errors caused by kernel decompression can be avoided, and the difficulty of debugging can be reduced.
4.2.4. PA/VA concept explanation and debugging essentials
In the source code arch/nds32/kernel/head.S
la $lp, __mmap_switched
mtsr $lp, $IPC
iret
After executing iret, the system will switch from PA to VA, and the MMU translation status from translation off to translation on. The debugging rules at this boundary are as follows. If the concept is not clear and it is easy to cause errors during debugging, please keep it in mind.
4.2.4.1. MMU translation off period debugging
During this period of debugging, VA does not exist. All IO address and memory are PA without VA. If the debugging address is set to VA, it is easy to hit illegal address and cause an exception.
4.2.4.2. MMU translation on period debugging
During this period of debugging, PA does not exist. All IO address and memory are VA without PA. If the debugging address is set to PA, it is easy to hit illegal address and cause exception.
4.2.5. Porting the basic components of Linux
After MMU translation on, it will soon enter the start_kernel function. The focus of the next transplant is to transplant the basic Linux components, that is, interrupt, timer and UART. When these three devices are successfully transplanted, the Linux architecture is established, printk can also be used, and Linux can already operate normally. If there is no accident, you can finish executing the kernel and even bring up the filesystem. Next, users can port their peripheral components one by one device driver into the system. When the peripheral components are transplanted, the Linux system is transplanted to the Andes platform.
5 ConclusionThe Linux operating system has been operating on the Andes platform for many years. There are countless kinds of Linux software running on the Andes platform. It can be proved that the operation of the Linux operating system combined with the Andes platform is a stable and mature product. As long as you are familiar with the skills and key points of Linux transplantation, using the Andes platform to develop Linux products will be a pleasant and simple task.
Guangzhou Bolei Electronic Technology Co., Ltd. , https://www.nzpal.com