1. Fundamentals of Kernel Development for BSP Engineers

Hello everyone, I am Sha Shixiong. We plan to start a series of topics called <span>Fundamentals of Kernel Development for BSP Engineers</span>.

I have been engaged in BSP development for many years, with extensive experience in chip validation and BringUp. Initially, I planned to update content related to chip BSP.

BSP development requires a certain foundation in kernel development, but I have not found suitable preliminary kernel materials.

Therefore, I want to organize a set of kernel knowledge that is truly used in driver and BSP development from the perspective of a BSP engineer, and delve into its principles, explaining it clearly to readers in my own way.

2. Learning Method

My document style tends to be practical, generally having strong guidance, allowing you to follow the document and operate without thinking. I advocate learning to use it first, and then delving into its principles from the usage methods.

The explanation approach in my series will use my daily work learning method, <span>What-How-Why</span>, which is very similar to piecing together a puzzle, so I call it the puzzle learning method.

This learning method is a very practical approach I have summarized from years of learning and work, closely aligned with real development work thinking, making it very suitable for engineers.

1. What: Before learning a knowledge point, first understand what it is, why to learn it, and what it will be used for after learning. This can quickly clarify learning objectives and master the direction of learning.

2. How: After understanding the basic concept of a knowledge point, the next step is to learn how to use it. For example, how to probe an I2C module in Linux, how to use i2ctool to debug I2C peripherals, etc. In real work, the process of developing a module is also to first familiarize and then use it.

3. Why: After learning to use it, the next step is to delve into the underlying implementation principles, which will deepen the understanding of this knowledge, allowing you to easily cope with various situations.

This learning process is like piecing together a puzzle. The first thing to do after getting the puzzle is to look at the cover, to understand what the final picture looks like, what characteristics the entire pattern has, and to have a rough direction in mind. Then, first piece together the edges of the puzzle to determine the boundaries. Finally, push inward continuously from the outside to complete the entire puzzle.

Achieving the first point can serve as a conversation starter, but it is easy for experienced engineers to tell that you have not truly done it.

Achieving the second point allows you to undertake related development work, but if you only stay at the application stage, you may find it difficult to cope when problems arise. Because the entire process is still a black box for you, and problems cannot be effectively controlled.

The last point is the difference between ordinary people and experts, which is a self-driven spirit that companies highly value in engineers. Being able to deeply understand the underlying implementation principles not only makes it easier to locate issues when they arise but also proves that you are an engineer with a spirit of inquiry.

Such engineers do not feel the so-called 35-year crisis. Because their work experience cannot be replaced by fresh graduates or newcomers with only a few years of experience.

However, because human energy is limited, and Linux has become extremely complex over time, it is impossible for an individual to be proficient in every subsystem.

Therefore, my suggestion is to master one or two specialties to achieve <span>know why</span>, and then in other related areas, aim for <span>know how</span>, and in as many fields as possible, <span>know what</span>.

For example, as a BSP engineer, you can master a high-speed bus (USB/ETH/UFS/PCIE), becoming familiar with its protocols, driver frameworks, debugging, and verification methods.

Then, have varying degrees of understanding of multiple low-speed subsystems, memory management, file systems, etc.

This is also what companies currently advocate as the so-called <span>T-shaped talent</span>.

3. Topic Content

My understanding of Linux BSP development = Linux driver framework + hardware controller protocols.

Therefore, the series on <span>Fundamentals of Kernel Development for BSP Engineers</span> will focus on explaining driver frameworks, kernels, peripheral driver development, etc., that are hardware-independent.

Content that is strongly related to specific hardware controllers will be explained in the BSP topic, making the content isolation more reasonable.

The currently planned content includes:

1. Compilation Details: Introduction to the kernel, learning kernel configuration and trimming, Kconfig syntax
2. Kernel Modules: The most common form of drivers
3. System Calls: How device drivers commonly use open/read/write
4. Character Device Drivers: The most common type of device driver
5. Device Model: The prototype of <span>platform</span><span> in the driver framework</span>
6. Platform Bus Device Driver Model: The <span>platform</span><span> driver framework is the foundation of BSP drivers</span>
7. Device Tree: Configuration and principles of dts
8. Interrupts: The Linux interrupt subsystem, which is very important for driver engineers
9. Concurrency Control: Atomic operations, spinlocks, semaphores, etc., are frequently used in device driver development
10. Memory Management in BSP Drivers: Differences and principles of vmalloc, kmalloc, and devm_kzalloc used in controller structures in BSP drivers

The above is the temporarily planned content, which may be adjusted based on updates. If there is anything you want to know, feel free to message me at any time.

4. Experimental Environment

Since this series will not involve specific hardware, the experimental platform will choose <span>QEMU</span><span>, and you can refer to: Ubuntu 24.04 + QEMU + ARMV8 + Linux 6.12 comprehensive development environment setup tutorial.</span>

5. Conclusion

Sharing this series is also a process of improving my personal abilities. Being able to explain things to others is the true understanding. Therefore, I hope:

1. Part-time creation is still quite challenging, and I welcome everyone to urge me to overcome procrastination
2. As mentioned earlier, no one can be omniscient. If there are any errors in the content, please feel free to point them out in a timely manner
3. If there are any unclear expressions or issues with experimental operations, please feel free to message me for discussion
4. If there are topics you want to know that are not in the content plan, you can also message me