Embedded Linux Development Process

Jacktang

Embedded Linux Development Process [Copy link]

In the process of learning embedded development, especially when you are just getting started, including various tutorials, they are all about learning Linux, and rarely about how to use Linux to develop your own embedded projects, that is, there is no overall concept. To understand it simply, the general process is as follows: 1. Establish a development environment. The operating system is of course Linux, or install a virtual machine under the win system, download the corresponding GCC cross compiler through the network to install it, or install the cross compiler provided by the product manufacturer. This step is equivalent to installing an IDE development environment, such as MDK, IAR, etc. under the win system. 2. Configure the development host mainly to configure minicom, which is the serial port assistant. The minicom software is used as a monitor and keyboard input tool for debugging the output of embedded development board information. It is a very convenient tool. When we develop other embedded programs, we actually use serial port debugging in many cases, so the final principles are the same. Configure the network, mainly to configure the NFS network file system, which is mainly used to download programs. Of course, it is also possible not to configure it, and there are many other ways. 3. Establish a bootloader to boot the program. Commonly used bootloaders are u-boot, vivi, etc. It seems that the mainstream is u-boot, which is transplanted and modified according to your specific chip. Some chips do not have built-in boot loaders, which requires writing some programs for the Flash on the development board. Of course, you can also use some Flash chip programs under Windows through the JTAG parallel port and emulator. There are also J-Flash programs with open source code under Linux, so when designing your own hardware, you can reserve multiple methods. Simply put, it is actually to make a u-boot for your own board, complete initialization, kernel boot, download, burn, etc. 4. Porting embedded Linux operating system If there is a Linux specifically for the CPU you use, it would be great, such as uCLinux, ARM-Linux, PPC-Linux, etc. If not, you should try to port your own Linux, and then add your own specific hardware driver for debugging and modification. For CPUs with MMU, you can use the module method to debug the driver, and for systems like uCLinux, you need to compile it into the kernel, integrate it with the kernel, and then debug it. 5. Establish a root file system The previous article mentioned that Linux cannot work properly without a root file system, and a root file system is also required. So you need to download and use busybox software to create a root file system. Then add other programs according to your own application needs. The default startup script generally does not meet the needs of the application (because all embedded development is freely customized), so you need to modify the startup script in the root file system. Its storage location is in the /etc directory, including: /etc/init.d/rc.S, /etc/profile, /etc/.profile, etc. The configuration file /etc/fstab that automatically mounts the file system is actually to customize the program you want to start at boot. The specific situation will vary with the system. The root file system is generally set to read-only in the embedded system, and you need to use tools such as mkcramfs and genromfs to generate a few image files. 6. To create the Flash disk partition of the application, jffs2 or YAFF file system is generally used, which requires the driver of these file systems to be provided in the kernel. Some systems use NOR FLASH, some systems use NAND FLASH, and some systems use both flash. So what is the role of jffs2? The introduction in the encyclopedia is: jffs2 is the full name of journalling flash filesystem version2 (flash journaling file system version 2), and its function is to manage the journaling file system implemented on the MTD device. The journaling system is also necessary for a complete system, whether it is Windows or Linux, it is not considered a hooligan, hehe. jffs2 does not intend to provide functions similar to traditional file systems. It will only implement a journaling structure file system directly on the MTD device. In addition to providing a journaling structure file system with power-off reliability, jffs2 will also implement "loss leveling" and "data compression" features on the MTD device it manages. MTD (memory technology device) is a variety of flash. 7. Developing applications Applications can be placed in the root file system, or in the yaffs or jffs2 file system. Some applications do not use the root file system, and directly design the application and the kernel together, which is similar to the uCOS-II method. In fact, as of now, this step is the ultimate goal. The previous steps are all for this step. In my opinion, there are three ways to develop application programs: (1) Directly design the application program and the kernel together, similar to the uCOS-II method. This method is customized. The types of functions implemented are relatively few. It is exclusive, but the stability requirements are high, such as complex switches, firewalls, etc., which may be more concerned with the stability of the Linux system and various excellent peripheral resources. (2) Develop applications based on GUIs such as Qt. I used to think that Qt was an indispensable part of Linux. In fact, as I get to know it better, it is not entirely true. Qt is actually a desktop system, such as Ubuntu. For experts, it doesn’t matter whether there is a desktop or not, because everything can be done through the shell. Using Qt is convenient for users, so for those embedded devices that need to be operated and have a screen, this is a good solution. For example, the current industrial control touch screens and various handheld instruments with screens are all this way. (3) There is no screen, only a simple human-machine interface, such as a serial port, a button, and a digital tube. This can also realize the development of complex functions. For example, it is entirely possible to develop a PLC based on Linux, a programmable solution, and implement it through a script. This is also a good solution. 8. Burning the kernel, the root file system, and the application program, no matter how it is loaded, whether it is a module, all these development and process data must be burned into the flash, and then the application program can load the corresponding function program as needed. 9. Release the product. At the end of the writing, I found that I was too superstitious about Linux before. It is not that Linux is not good, but that for embedded development engineers, there is no best, only the most suitable. When developing a product, what to use and what not to use are all based on local conditions. For example, for a simple marquee, if you insist on using an embedded Linux solution, it is a waste of money. You only need a simple 2051 and a bare metal program to develop it, which is both cheap and easy to use. To develop a small controller device, if the function is not too complicated, you can use a slightly advanced CPU, bare metal or ucos, etc. to develop it, which is also very convenient, and can also make many customized versions of industrial small controllers. If you want to develop a mid-to-high-end controller device with complex functions or even complex screen interaction, such as mobile phones (Android is the son of Linux, and OS is the cousin of Linux), ATMs, and server trading systems, then Linux is very suitable.