Students who are just beginning to learn embedded may be confused about embedded. They may have studied for a few weeks but still do not know what embedded is. Then I will introduce to you what embedded linux includes. Embedded LINUX contains four large blocks: bootloader, kernel, driver, and root file system.
Beginners Learning Embedded Beginners to Embedded Beginners
1. Bootloader:
It's a slightly more complicated bare-board program. But it is not easy to understand and write this bare board program well. The useful tools under Windows weaken our programming ability.
Many people use ADS and KEIL when they play embedded. Can you answer these questions?
1. Once powered on, where does the CPU fetch instructions for execution?
Answer: Generally, the command is from Flash.
2. But Flash can only be read and cannot be written directly. If I use global variables, where are these global variables?
Answer: Global variables should be in memory
3. So who puts global variables in memory?
A: Friends who have used ADS and KEIL for a long time, can you answer them? This requires "relocation". In ADS or KEIL, the relocation code is written for you by the company that makes the tools.
Have you ever read it?
4. With such a large memory, how do I know to read "the content originally stored in the Flash" to "where to go" in the memory?
Answer: This address is determined by "link script", there are scatter files in ADS, and there are similar files in KEIL. But have you done research?
5. You said that relocation is to copy the program from Flash to memory, so this program can read Flash?
A: Yes, to be able to operate Flash. Of course not only these, but also set the clock to make the system run faster and so on.
Let’s start by asking and answering here. Bootloader, a bare-board program, actually has three main points:
1. Operation on the hardware
2. Knowledge of ARM-based processors
3. Basic concepts of programs: relocation, stack, code segment, data segment, BSS segment, etc.
For the operation of the hardware, you need to see the schematic diagram and the chip manual. This requires a certain knowledge of hardware. You are not required to be able to design hardware, but at least you can understand it; you do not need to be able to understand analog circuits, but you must be able to understand digital circuits. I learned this ability in school, and the two books (forgot the title) of microcomputer principles and digital circuits are enough. But I doubt that you have the patience to read these two books. I don't know if there are any faster books out there. If you want to make it fast, let it go first, and if you don't understand it, ask GOOGLE and post it.
In addition, the chip manual must be read, don't look for Chinese, just look at English. It is very painful at first, but later you will find that once you are familiar with the grammar and vocabulary, it is easy to read any chip manual.
For the understanding of the ARM system processor, see Du Chunlei's "ARM Architecture and Programming", which talks about assembly instructions, exception mode, MMU, etc. That's all you need to know about these 3 things.
The basic concept of the program, of course, the kingly way is to see the compilation principle. Unfortunately, this kind of book is absolutely heavenly. I advise you not to watch it unless you are a super genius. Just look at the "Complete Handbook of Embedded Linux Application Development" and the first video I wrote, don't worry, don't spend money. The hardware-related experiments were done according to the video, and these concepts became clear. I have yet to find a second set of books or videos on these concepts that allows me to brag.
As for the bootloader, I first read <ARM Architecture and Programming> when I was studying, and then I wrote the program myself to do the experiments on various hardware, such as GPIO, clock, SDRAM, UART, and NAND. It's easy to understand u-boot once you have them all figured out
To sum up, to understand the hardware schematic diagram and read the chip manual, you need to find the information yourself. For the rest, just follow the chapter list of <Embedded Linux Application Development Complete Manual> and the first video.
2. Kernel:
Those who want to speed up, first step over the learning of the kernel, and directly learn how to write drivers.
To become a master, you must have a deep understanding of the kernel. Note, I'm talking about understanding, I don't have the luxury of writing a kernel.
It is necessary to understand the scheduling mechanism, memory management mechanism, file management mechanism and so on.
Two books are recommended:
1. Read through <Linux Kernel Complete Comments>, please read the book of Bo (the boring society demands speed, hehe),
2. Select <Linux Kernel Scenario Analysis>, read which section if you want to know which part
3. Drive:
The driver consists of two parts: the operation of the hardware itself, and the framework of the driver.
It's hardware again, you still have to understand the schematic diagram and read the chip manual, and practice more.
When it comes to driver frameworks, there are some books that introduce them. LDD3, that is, <Linux Device Driver>, the book written by foreigners, which introduces a lot of concepts, it is worth reading. However, its role is limited to introducing concepts. I basically use it to get acquainted with the concepts before getting started, and throw it away after getting started.
For a more comprehensive introduction to the driver, it should be Song Baohua's "Detailed Explanation of Linux Device Driver Development". To be honest, I have only read the directory. Many people said that it is good, and I recommend it here.
If you want to understand a certain piece in depth, <Linux Kernel Scenario Analysis> is definitely a super 5-star recommendation. Don't expect to read it through, it's over 1,800 pages and two volumes. When I'm not sure about a certain piece, I'll look it up. Any part, the book can cover 2 or 3 hundred pages, very detailed. And take you to analyze the kernel source code with a certain target. It takes linux 2.4 as an example, but the principle is the same, and it is also applicable to other versions of linux.
1. Use the drawing board to draw and explain - it is equivalent to the teacher in the school drawing and explaining on the blackboard. It is very intuitive and definitely not reading to PPT.
2. Use source insight to write programs on the spot, starting from line 1, every lesson is like this. I talked about more than 20 drivers and wrote more than 20 programs.
3. Compile and test after writing.
4. Very comprehensive, three categories of character device drivers, block devices, and network card drivers are complete, and three categories of hardware introduction, driver framework analysis, and testing are complete.
I have taught classes in the Maker Academy, and I have never seen any teacher who dares to explain every class on the spot, write code on the spot, and test it on the spot, except me! Try to write a driver for the hardware involved in your development board. If there is a problem, "think painfully" first. In the process of thinking, you will connect a lot of irrelevant knowledge, and finally get through.
Fourth, the root file system:
Have you ever thought about these two questions:
1. For products made by Linux, some are used for monitoring, some are used as mobile phones, and some are used as tablets. Then after the kernel is started and the root file system is mounted, which application should be started?
Answer: The kernel does not know and does not care which user program should be started. It only starts the init application, which corresponds to /sbin/init.
Obviously, this application needs to read the configuration file and start the user program (monitor, manual interface, tablet interface, etc.) according to the configuration file. This question reminds us that the content of the file system has some conventions, such as /sbin/init and configuration files.
2. Have you ever wondered who implemented the printf used in the hello, world program you wrote?
Answer: This function is not implemented by you, it is implemented by the library function. When it runs, it has to find the library.
This question reminds us that there are also libraries in the file system.
Here is a simple question and answer. If you want to know more, you can look at the init.c of busybox, and you can know what the init process does.