Embedded Linux and Android Learning Roadmap

Website/Forum: www.100ask.net, www.100ask.org

Taobao: 100ask.taobao.com

Email: [email protected]

WeChat Official Account: baiwenkeji

Company Weibo: 百问科技

Personal Weibo: 韦东山

Version: V1

Date: 2016.07.29

Author: 韦东山

Description: Version 1, Android part not written

I entered university in 1999, majoring in physics. During my freshman year, there was a general sense of unease in our class about the future, unsure of what we could do with a physics degree. Your current experiences and studies will definitely impact your future. After graduation, we each found our own paths: pursuing further studies abroad and switching to finance, staying in school to teach and conduct research, designing chips, writing programs, starting companies, etc. All of this is rooted in the foundational skills (mathematics, IT, electronic circuits) and the self-learning abilities we honed during our time in school.

So, to all the confused students and programmers trying to switch careers, there is definitely a place for you in the future; whether it is good or bad depends on your current efforts and accumulation.

I cannot predict which industries will be popular in a few years, nor can I guarantee that following this article will make you wealthy. I am just a programmer with over a decade of experience, offering some advice to those interested in programming.

1. The Three Major Directions for Programmers

Programmers can generally be divided into three categories: Specialized Fields, Business Fields, and Operating System Fields. After understanding them, choose based on your interests.

For specialized fields, I cannot provide advice.

Business refers to application programs, which are not completely separate from operating systems:

1) When developing physical products, those who write application programs well sometimes need knowledge of operating systems, such as setting scheduling priorities and knowing that certain functions may cause processes to sleep.

2) When someone who writes application programs advances to a system engineer, they need to understand the entire system from top to bottom, which requires knowledge of the operating system field; otherwise, how can you design the entire system’s solution?

3) Those who create application programs need to understand industry demands and business logic. Therefore, leaders are often those who work on applications. Once you dive into a certain industry, it is difficult to switch industries.

4) In the operating system field, doing well can allow you to work across all industries: it only handles the underlying systems, and what business is developed on top of it is irrelevant to them. Many in this field are technical experts.

5) There is no clear boundary between operating systems and business. Having operating system experience and then doing applications will give you a deep understanding of the system, and you will have ideas for solving problems when you encounter them. With business experience, if you then learn about operating systems, you can quickly form a team and become independent, at least making it as a CTO is not a problem.

1.1 Specialized Fields

These can be further divided into two categories.

1.1.1 Academic Research

For example, speech, image processing, artificial intelligence; this type of work requires strong theoretical knowledge. I tend to think of these people as “scientists” who have researched for many years, often engaged in academic research.

In the embedded field, their results need to be expressed using certain algorithms and optimized for certain chips; this part of the work may be done by specialists.

1.1.2 Engineering Implementation

There are also those who understand the concepts of these specialized fields but have not delved deeply. They can use various open-source materials to achieve a goal and produce products. For example, in image processing, they know how to use the hundreds of complex functions in OpenCV to achieve face recognition. Sometimes they can also optimize these functions based on specific chips.

“Specialized fields” are not my forte. If you want to work in this area, I think the best way to get started is to study graduate or doctoral courses at school.

1.2 Business Fields

In other words, this refers to application programs, which can also be divided into two categories.

1.2.1 User Interface Display

Creating products requires good interfaces, but it is not that important; it lacks development potential.

The current buzzwords are Android APP and iOS APP development. Don’t be fooled by the words Android and iOS; they are just like the old VC and VB, merely a set of GUI controls implementations.

I hope I haven’t offended you; I have my reasons.

A program needs to have a GUI interface, but the internal logic of the program is the core. The development tools for Android and iOS simplify GUI development for us and provide interaction mechanisms for these controls, encapsulating and providing some services (like network transmission).

However, the internal business logic of the program, processing video, images, sounds, etc., is the core.

Also, don’t forget about the backend programs on the server side: how to securely store data, protect customer privacy, handle thousands or millions of concurrent accesses, etc., these are also core tasks.

However, entering the field from Android or iOS APP is quick! If you are a senior, eager to find a job, then spending 1-2 months learning Android or iOS should make it easy to find a job, as the demand for APPs is always the highest, and these two technologies are still relatively popular.

In around 2011-2012, the starting salary for Android programmers was quite high but started to decline. The entry-level for Android APP development only takes about a month, so more and more people are getting into it.

By 2013-2014, the salaries for iOS developers were noticeably higher than for Android, leading to a boom in various iOS training programs. China has never lacked for talent that can quickly learn; it is estimated that after a while, iOS engineers will also be at a low price.

Knowing Android and iOS is just the basic requirement; just search for Android or iOS jobs on 51job, and you will definitely see other requirements in the job descriptions.

1.2.2 Business Logic

Take a simple example: when making a clock-in software, you need to consider these things:

1) The normal process requires clocking in when starting and ending work.

2) What if someone forgets? Record it as an exception and notify the administrator.

3) How to handle leave requests?

4) How to handle overtime?

For more complex examples, in a video conferencing system, how various modules connect, how to ensure compatibility with various protocols, if you do not delve into this industry, you will not understand it at all.

The number of application development positions is always the highest, and the entry barrier is low. Basically, as long as you know C language and perform decently in interviews, most companies will give you a chance because:

1) After you join the company, you will still need to be retrained: familiarizing yourself with their business logic.

2) What you will do is primarily modules; the framework has already been set up for you, and you just need to fill in the code.

Let me say something to make you happy: in software companies, most leaders are those who write application programs (of course, there are also those in marketing). Those who write application programs can research the market and meet customers externally and manage programmers to complete development internally; if they are not made leaders, who else should be?

If your ambition is to write application programs, I suggest you practice your basics well: data structures and algorithms are essential, and then choose to delve into databases, network programming, etc. based on your interests.

Finally, choose an industry you are optimistic about and interested in, and dig deep for about ten years. Once a person involved in application development chooses a certain industry, it is very difficult to switch industries later; choosing the right industry is crucial!

1.3 Operating System Fields

UCOS is too simple, VxWorks is too expensive and specialized, Windows is no longer used in embedded systems, and iOS is not open source; therefore, in the operating system field, we can only play with Linux.

In the embedded field, Linux is the dominant player!

What about Android? Android, like QT, is a GUI system. However, Google’s power is so strong that Android is now ubiquitous, which is why many times Linux + Android has become the standard configuration. Note that here we are concerned about the entire system of Android, its mechanisms, rather than just learning a few APIs and developing interface programs.

The contents included in the operating system field can be simply stated as creating a dedicated “computer” with the system installed, which can be divided into:

1) Planning hardware for products:

Choose the main chip according to needs, performance, and cost, and match it with peripheral devices, handing it over to hardware developers for design.

2) Making single-board computers, installing operating systems, and writing drivers.

3) Customizing maintenance, upgrades, and system solutions.

4) You may also need to configure and install GUI systems like Android:

5) Configuring the development environment for application developers.

6) Solving difficult problems from a system perspective.

This field is often referred to as “low-level systems” or “driver development”.

Let’s clarify two common misconceptions:

1) Is this job about writing drivers?

Looking at the six points listed above, it should be said that it includes driver development, but it is far from limited to driver development.

2) Do we still need to write drivers? Aren’t there manufacturers who have already provided them? Or can we just modify them? Many people often say that chip manufacturers have already done the drivers; just take them and modify them. If your hardware is exactly the same as the manufacturer’s public board, the manufacturer’s source code has no bugs, and you do not want to optimize performance, reduce costs, or create unique products, then this statement is correct.

But in this age where not innovating means failure, is that possible?! There are two reasons:

1) Even if you are just modifying the code, the premise for modification is understanding; the best way to understand is to write several drivers from scratch.

2) Often, you need to customize the system deeply.

Previously, when making MediaTek phones, only minor modifications to the interface were needed to ship; now many counterfeit manufacturers are going under. When everyone uses the manufacturer’s solutions without modification, they can only compete on cost.

For example, in Shenzhen, there are two manufacturers of traffic cameras and surveillance cameras; they once asked me to do four projects:

1) Improve the SD card driver performance provided by the manufacturer using DMA.

2) After changing the Flash model, the system often has problems, requiring modifications to the driver bugs.

3) Touchscreen clicks are inaccurate; after investigation, it was found that bypass capacitors were the cause.

4) Reducing costs by changing four DDR chips to two DDR chips requires modifying the bootloader for DDR initialization.

These projects were all urgent; if they could not be resolved, products could not be shipped. At this time, would you go to the manufacturer? Unless you are a major client like ZTE or Huawei, who would care?

When I worked at ZTE, I spent very little time writing drivers; most of the time was spent debugging: optimizing the system, helping APP engineers above, and assisting hardware engineers below in troubleshooting.

Much of the source code we obtained from manufacturers or online was standard, and of course could be used directly. However, optimizing it for your product may yield better results. For example, we can combine the camera driver and DMA driver so that the camera’s data is sent directly to the DSP via DMA.

We can act as a bridge between software and hardware; for physical products, software problems may arise, and hardware problems may also arise. Generally, it is easier for low-level system engineers to identify issues.

When hardware or software applications have issues they cannot resolve, they can provide suggestions and tools from the perspective of low-level software.

For example, in solution selection: whether the chip’s performance meets standards, whether the available BSP is complete, etc., this can only be considered by the person responsible for the entire solution; they must understand the fundamentals.

In the operating system field, the knowledge requirements are extensive:

1) Understand hardware knowledge to read circuit diagrams.

2) Good English to read chip manuals.

3) Ability to write and port driver programs.

4) A certain understanding of the operating system itself to solve various problems.

5) Understand the internal mechanisms of Android.

6) Knowledge of assembly, C, C++, JAVA.

It is definitely a big pit; those without interest or perseverance should choose carefully.

1) The entry into this field requires at least six months, even if studied full-time.

2) The number of positions in this field is definitely less than those for APPs.

3) Without 1-2 years of experience, when you are hired, you will initially still work on APPs.

The advantages are:

1) Once you learn well, you can work across industries; if you want to switch industries, you can.

2) Compared to those who develop applications, you won’t be constantly bothered by changing demands that lead to overtime.

3) Higher entry barriers mean higher salaries.

In the operating system field, I think it is suitable for these people:

1) Hardware engineers wanting to transition to software engineers; starting from low-level software would be better.

2) Microcontroller engineers wanting to upgrade. Those who know Linux at a low level will definitely know microcontrollers, but those who know microcontrollers may not necessarily know Linux.

3) Students with sufficient time: if you are in your second or third year, spending six months learning embedded Linux at a low level will be very beneficial.

4) Those wanting to master the entire system; for example, if you are currently writing APPs in a company but want to become a system engineer, then the low-level knowledge is essential.

5) Engineers wanting to start their own physical products; if you have money, you don’t need to learn any technology, but if you don’t have money and want to create products, then learning Linux at a low level is a must.

6) Those who develop Linux APPs; they also need to learn.

These individuals do not need to delve deeply; a general understanding will suffice: bootloader is used to start the kernel, the Linux file system (what the first program is, what it does, what each directory is for), the relationship between APPs and driver program calls, having these concepts will be enough.

In this article, we assume the operating system is Linux and discuss how to learn the embedded Linux + Android system.

1.4 What Does Embedded Linux + Android System Include?

What does the embedded Linux system include? Don’t worry; you’ll understand with an example.

1) When a computer starts up, who displays those interfaces?

It is the BIOS. What does it do? Some self-checks, then reads Windows from the hard drive and starts it.

Similarly, this BIOS corresponds to the bootloader in embedded Linux. This bootloader needs to read the Linux kernel from Flash and start it.

2) What is the purpose of starting Windows?

Of course, to run applications for browsing the internet, chatting, etc.

Where are these internet programs and chat programs?

On the C drive and D drive.

So, Windows needs to recognize the C drive and D drive. In Linux, we refer to this as the root file system.

3) If Windows can recognize the C drive and D drive, it must have the ability to read and write to the hard drive.

This ability is what we call driver programs. Of course, it’s not just operating the hard drive; there are also other hardware like network cards and USB.

The embedded Linux system can read and execute application programs from Flash, which also requires having the Flash driver, of course, not just Flash.

Simply put, the embedded LINUX system consists of five major components: bootloader, kernel, driver programs, root file system, and application programs. The application programs can be further divided into: C/C++ and Android.

Therefore, the embedded Linux + Android system includes the following six parts:

1) Bootloader

2) Linux Kernel

3) Driver Programs

4) Application Programs written in C/C++

5) The Android system itself

6) Android Application Programs

The connection between Android and Linux is significant; its applications are so widespread that once you learn Linux, there is no reason to stop learning Android. In most smart devices, the operating system running is Linux; it either has Android installed or can connect with Android phones. Now, Linux + Android has become the standard configuration.

2. How to Learn Embedded Linux Operating System

This article assumes you are starting from scratch, focusing on practicality, and aims to get you started in the shortest time; references for further study will be attached later.

In actual work, we engage in development around the “operating system” and do not delve too deeply into learning or modifying the operating system itself.

1) The operating system has stable and reliable core functions such as process management, storage management, file management, and device management, which generally do not require us to modify code. We only need to improve driver programs for our hardware.

2) Learning drivers will inevitably involve other knowledge, such as storage management and process scheduling. Once you deeply understand driver programs, your understanding of other parts of the operating system will also deepen.

3) Most of the code in the Linux kernel is device driver programs; it can be considered that the Linux kernel consists of various drivers.

However, to become an expert in this field, you must deeply understand the Linux operating system itself and read its source code.

In your spare time after work, you can look at these books:

1) Zhao Jiong’s “Complete Commentary on Linux Kernel”; this one is relatively thin and recommended. He later published “Complete Analysis of Linux Kernel,” which is too thick; if you are not careful, you might forget the earlier parts after reading the latter.

2) Mao Decao and Hu Ximing’s “Scenario Analysis of LINUX Core Source Code”; this book is divided into two volumes and is extremely thick. You can use it as a dictionary: if you want to understand certain knowledge, just look at the relevant chapter.

3) There are many other good books, but I haven’t read them much, so I have no more recommendations.

Based on the goal of quickly getting started and being ready for work, you don’t need to read the above books first; just follow this article to study.

2.2 Basic Knowledge Before Learning Driver Programs

2.2.1 C Language

It seems that all engineering majors teach C language. I have seen many students who score 90 or 100 in C language exams but are dumbfounded when they sit at a computer; I suspect they have never written a program on a computer.

Theory is great, but if you can’t practice, what use is it for a company to hire you?

Conversely, practice is the true knowledge; learning C language requires practice, practice, and more practice!

Once you master the basic syntax, you can practice some C language exercises on your computer.

After writing a few C programs, you can move on to the next stage of bare-metal development.

1) You don’t need to go too deep.

As a quick start, just being able to write “Hello, world!”, implement bubble sort, and have some basic syntax operations is enough for now.

Pointer operations are key; practice them more.

You do not need to learn excessive data structure knowledge; just mastering linked list operations is sufficient, while you do not need to learn about queues, binary trees, etc.

You do not need to learn any function usage, such as file operations, multithreading programming, network programming, etc.;

These knowledge will be used when writing Linux application programs, but they are not needed when learning operating systems, especially drivers!

Keep moving forward; if you encounter any C language problems later, we can go back and learn.

In the subsequent “bare-metal development,” you will continue to practice C language, which will be more practical.

C language is refined through writing code.

2) You can learn it under Visual Studio or Linux; the latter requires you to master some compilation commands.

We have not provided a C language tutorial for now; just find a C language book or look for free C language videos online (mainly to see how to set up the environment), and you can self-learn.

2.2.2 Basic Operations of PC Linux:

For PC Linux, we recommend using Ubuntu, as it is very easy to install software on it.

Our work mode is usually like this: reading and writing code under Windows, and then uploading the code to PC Linux for compilation.

In fact, the desktop system of Ubuntu is already very usable; we can quickly get started with various smart machines, and I believe the desktop system of Ubuntu can also help you get started quickly.

To improve work efficiency, we usually use the command line to operate Ubuntu.

Don’t worry; for the initial stage, you only need to master a few commands, which are so simple that I will list them:

1) cd: Change Directory

cd directory_name // Enter a certain directory

cd .. // cd “two dots”: Return to the previous directory

cd – // cd “hyphen”: Return to the last directory

2) pwd: Print Work Directory (prints the absolute path of the current working directory)

3) mkdir: Make Directory

mkdir abc // Create folder abc

mkdir -p a/b/c // Create folder a, then create folder b under a, and then create folder c under b

4) rm: Remove (delete directory or file)

rm file // Delete the file named file

rm -rf dir // Delete the directory named dir

5) ls: List (list directory contents)

6) mount: Mount

mount -t nfs -o nolock,vers=2 192.168.1.123:/work/nfs_root /mnt

mount -t yaffs /dev/mtdblock3 /mnt

7) chown: Change owner (change the file’s owner)

chown book:book /work -R // Change the owner of the /work directory and all its contents to the user book and group book

8) chmod: Change mode (change permissions); the following example is very simple and straightforward

chmod 777 /work -R // Change the permissions of the /work directory and all its contents to readable, writable, and executable

9) vi: The most commonly used editing command under Linux; its usage is slightly complex, so please search for its usage yourself.

To practice these commands, you can enter the Ubuntu desktop system and open the terminal to input those commands; or use tools like SecureCRT or putty to log in remotely to Ubuntu and practice.

2.2.3 Hardware Knowledge

Our goal in learning hardware knowledge is to understand circuit diagrams, communication protocols, and chip manuals; we do not seek to design circuit diagrams, let alone design circuit boards.

For the proper method, you should study like this:

1) Study “Microcomputer Principles” to understand the composition of a computer and the interaction principles of its various components.

2) Study “Digital Circuits” to understand the principles and uses of various gate circuits, and also master some logic operations (AND, OR, etc.).

3) “Analog Circuits”? Well, this one is not necessary; at least I have not used it in my work and have completely forgotten it now.

In my personal experience, these courses are useful, but:

1) The principles are useful, but they lack practical application.

For example, “Microcomputer Principles” is based on the x86 system, which is quite different from ARM boards, but the principles are similar.

I only understood these courses after I got into embedded programming.

2) Each book is so thick, with a lot of content, making learning time-consuming and self-learning difficult.

To address the shortcomings of these campus textbooks and in combination with the knowledge points needed in actual development, we launched the “Pre-school Class: How to Read Circuit Diagrams” video series:

Pre-school Class Lesson 1 Section 1: How to Read Circuit Diagrams of GPIO and Gate Circuits.wmv

Pre-school Class Lesson 1 Section 2.1: How to Read Circuit Diagrams of Protocol Interfaces: UART.wmv

Pre-school Class Lesson 1 Section 2.2: How to Read Circuit Diagrams of Protocol Interfaces: I2C.wmv

Pre-school Class Lesson 1 Section 2.3: How to Read Circuit Diagrams of Protocol Interfaces: SPI.wmv

Pre-school Class Lesson 1 Section 2.4: How to Read Circuit Diagrams of Protocol Interfaces: NAND Flash.wmv

Pre-school Class Lesson 1 Section 2.5: How to Read Circuit Diagrams of Protocol Interfaces: LCD.wmv

Pre-school Class Lesson 1 Section 3: How to Read Circuit Diagrams of Memory Interfaces.wmv

Pre-school Class Lesson 1 Section 4.1: How to Read Circuit Diagrams: Analyzing the S3C2410 Development Board.wmv

Pre-school Class Lesson 1 Section 4.2: How to Read Circuit Diagrams: Analyzing the S3C2440 Development Board.wmv

Pre-school Class Lesson 1 Section 4.3: How to Read Circuit Diagrams: Analyzing the S3C6410 Development Board.wmv

Even if you only have the circuit knowledge from junior high school physics, I hope that through these videos, you can understand circuit diagrams and some common communication protocols; if you wish to master more hardware knowledge, these videos can also serve as an index to let you know what knowledge you lack.

The hardware knowledge mentioned in these videos will be used in the “Bare-board Development” video series, allowing you to reference them for better understanding.

2.2.4 Should You Specifically Learn Microcontroller Development on Windows?

Many schools offer microcontroller courses, and many people start from 51 microcontrollers, AVR microcontrollers, and now relatively new STM32 microcontrollers to get into the embedded field, using Windows development software like Keil, MDK, etc.

The question arises: should you specifically learn microcontroller development on Windows?

1) If this is a required course for your major, then learn it.

2) If your major is closely related to microcontrollers, such as mechanical control, then learn it.

3) If you just want to get started with microcontrollers and then learn more about embedded Linux, then give up learning microcontrollers on Windows!

Here are the reasons:

1) Learning microcontrollers on Windows lacks depth.

Windows has good graphical interface microcontroller development software, such as Keil, MDK, etc.

They encapsulate many technical details, such as:

You will start writing code from the main function but will not know how the first line of code is executed after powering on;

You can write interrupt handling functions, but you will not know how they are called;

You do not know how programs are read from Flash into memory;

And you do not know how memory is allocated and used, where the stack is, where the heap is;

When you want to trim the program to reduce Flash and memory usage, you will have no clue;

When you create a new file, it is automatically added to the project, but you completely do not understand the mechanisms involved;

And so on.

2) Learning ARM + Linux bare-metal development allows for deeper learning and is more aligned with subsequent Linux studies.

In fact, it is just microcontroller learning under Linux, but everything is more primitive: all code needs to be written by you; you need to manage which files are added to the project.

In work, we certainly prefer to use more convenient tools under Windows, but in the learning stage, we want to learn the essence of programming:

You need to understand the power-on startup process of the chip and know how the first line of code runs;

You need to master how to read programs from Flash into memory;

You need to understand how memory is allocated, such as where the stack is, where the heap is;

You need to understand code relocation;

You need to know how interrupts occur and how both hardware and software protect the scene, jump to the interrupt entry, call the interrupt program, and restore the scene;

You will know that the main function is not the first function we write;

You will know that from the moment the chip is powered on, how the program is executed;

You will know how parameters are passed during function calls;

You will know that every register value must be treated with caution when an interrupt occurs;

And so on.

Once you master ARM + Linux bare-metal development, looking back at microcontroller development on Windows will seem so simple! And you will fully understand the technical details that these tools do not show you.

Driver programs = Linux driver program software framework + ARM development board hardware operations. We can start with simple bare-metal development to master hardware operations, and we can also:

1) Master how to compile programs under PC Linux, burn the programs to the board, and run them.

2) Lay the foundation for learning bootloader: after mastering various hardware operations, the next combination will be a bootloader.

2.2.5 Why Choose the ARM9 S3C2440 Development Board Instead of Other Higher-Performance Ones?

There is a misconception that S3C2440 is outdated, and ARM9 is outdated.

This is incorrect; if you are a software engineer, whether it is ARM9, ARM11, A8, or A9, there is no difference for us.

A chip has a CPU and numerous on-chip devices (such as UART, USB, LCD controllers). When we write programs, we do not deal with the CPU; we only operate those on-chip devices.

Thus, the difference lies in the on-chip devices, not in the CPU core; the difference lies in the operations of the registers.

The reason for recommending S3C2440 is that its Linux learning materials are the most abundant and it has matching first and second phase videos.

2.2.6 How to Learn ARM + Linux Bare-metal Development

The purpose of learning bare-metal development is twofold:

1) To master the structure of bare-metal programs in preparation for subsequent u-boot development.

2) To practice hardware knowledge: how to read circuit diagrams, chip manuals, and how to write code to operate hardware.

The subsequent u-boot can be regarded as a collection of bare-metal programs; we master each component in bare-metal development, and then combine them to obtain a u-boot.

The subsequent driver development also involves hardware operations, and you can learn hardware knowledge in bare-metal development.

Note: If you are not concerned about the structure of bare-metal programs or the implementation of bootloaders, this part can be skipped for now. In the later driver videos, we will also re-explain the hardware knowledge involved.

Two books are recommended: Du Chunlei’s “ARM Architecture and Programming” and Wei Dongshan’s “Complete Manual for Embedded Linux Application Development”. The latter may be the first book in China that involves developing ARM bare-metal programs in a PC Linux environment; if I am wrong, please forgive me for not reading many books.

For bare-metal development, we provide two parts of videos:

1) Environment Setup

Lesson 0 Section 1: Just Getting Started with the Development Board – Interface Wiring.wmv

Lesson 0 Section 2: Just Getting Started with the Development Board – Burning Bare-board Programs.wmv

Lesson 0 Section 3: Just Getting Started with the Development Board – Reburning the Entire System.wmv

Lesson 0 Section 4: Just Getting Started with the Development Board – Using VMware and Pre-made Ubuntu.wmv

Lesson 0 Section 5: Just Getting Started with the Development Board – Patching and Compiling u-boot and Building Source Insight Projects.wmv

Lesson 0 Section 6: Just Getting Started with the Development Board – Patching and Compiling Kernel u-boot and Building Source Insight Projects.wmv

Lesson 0 Section 7: Just Getting Started with the Development Board – Creating Root File System and Initial Driver Testing.wmv

Lesson 0 Section 8: Setting Up the System Used in Videos on TQ2440, MINI2440.wmv

Lesson 0 Section 9: Alternative Method for Burning on Win7 When DNW Cannot Be Used.wmv

2) Bare-metal Program Development

Lesson 1: Environment Setup and Tool, Concept Introduction.wmv

Lesson 2: GPIO Experiment.wmv

Lesson 3: Storage Manager Experiment.wmv

Lesson 4: MMU Experiment.wmv

Lesson 5: NAND FLASH Controller.wmv

Lesson 6: Interrupt Controller.wmv

Lesson 7: System Clock and UART Experiment.wmv

Lesson 8: LCD Experiment.wmv

To declare:

When recording the above “Bare-metal Program Development” videos, the intention was to explain it in conjunction with the “Complete Manual for Embedded Linux Application Development”‘s “Part 2: Basic Examples of ARM9 Embedded Systems”; thus, the videos do not completely start from scratch in code writing, and you need to learn in conjunction with the book.

1) The book and the videos are not completely matched, so do not copy them; the differences are not hard to resolve.

The “Complete Manual for Embedded Linux Application Development” was published in 2008 and used many development boards; at that time, the configurations of development boards were relatively low (NAND Flash was 64M);

The “Bare-metal Program Development” videos were recorded using the JZ2440 development board.

2) The book and videos apply to all S3C2440 development boards, including mini2440, tq2440, etc.

All S3C2440 configurations are similar; basically, only the LED and button pin assignments differ, and the LCD models differ; if you learn the book and videos but cannot figure out these differences, that would be a failure on both our parts.

The learning method is as follows:

1) First, watch the “Environment Setup” video to set up the development environment.

2) Combine the book (Part 2) and the videos (bare-metal program development); after finishing a chapter, practice that chapter.

Make sure to write code, even if it is just copying!

3) If you find the knowledge related to the ARM architecture vague or want to understand it more deeply, refer to “ARM Architecture and Programming”.

Learning Level:

1) Understand the necessary structure of a bare-metal program: exception vectors, hardware initialization, code relocation, stack.

2) Know how to operate GPIO, Flash, LCD, touchscreen, and other hardware.

3) Many people find MMU difficult to understand; you can skip it.

2.2.7 Learning Bootloader

There are many types of bootloaders, such as vivi, u-boot, etc.; the most commonly used one is u-boot.

U-boot is powerful, and the source code is relatively abundant; for those with little programming experience or experience reading code, it may seem difficult to grasp at first.

However, the main function of u-boot is to start the kernel. It involves: reading the kernel into memory, setting startup parameters, and starting the kernel. Following this main line, we try to write a bootloader from scratch; this program is relatively simple and can help us quickly understand the implementation of u-boot’s main functions.

Videos for writing bootloaders from scratch include:

Graduation Class Lesson 1 Section 1: Writing Bootloader from Scratch – Phase 1.wmv

Graduation Class Lesson 1 Section 1.2: Writing Bootloader from Scratch – Phase 2.wmv

Graduation Class Lesson 1 Section 2: Writing Bootloader from Scratch – Compilation and Testing.wmv

Graduation Class Lesson 1 Section 3: Writing Bootloader from Scratch – Improvements.wmv

Videos for analyzing u-boot 1.1.6 include:

Lesson 9 Section 1: Analyzing u-boot – Compilation Experience.wmv

Lesson 9 Section 2: Analyzing u-boot – Makefile Structure Analysis.wmv

Lesson 9 Section 3: Analyzing u-boot – Source Code Phase 1.wmv

Lesson 9 Section 3: Analyzing u-boot – Source Code Phase 2.wmv

Lesson 9 Section 4: Analyzing u-boot – Implementing u-boot Commands.wmv

Lesson 9 Section 5: Analyzing u-boot – u-boot Starts the Kernel.wmv

Videos for porting a new u-boot include:

Graduation Class Lesson 2 Section 1: Porting the Latest u-boot – Initial Test.wmv

Graduation Class Lesson 2 Section 2.1: Porting the Latest u-boot – Analyzing the Startup Process Overview.wmv

Graduation Class Lesson 2 Section 2.2: Porting the Latest u-boot – Analyzing the Startup Process Memory Distribution.wmv

Graduation Class Lesson 2 Section 2.3: Porting the Latest u-boot – Analyzing the Startup Process Relocation.wmv

Graduation Class Lesson 2 Section 3.1: Porting the Latest u-boot – Modifying Code to Support New Boards, Clock, SDRAM, UART.wmv

Graduation Class Lesson 2 Section 3.2: Porting the Latest u-boot – Modifying Code to Support NAND Boot.wmv

Graduation Class Lesson 2 Section 3.3: Porting the Latest u-boot – Modifying Code to Support Nor Flash.wmv

Graduation Class Lesson 2 Section 3.4: Porting the Latest u-boot – Modifying Code to Support Nand Flash.wmv

Graduation Class Lesson 2 Section 3.5: Porting the Latest u-boot – Modifying Code to Support DM9000 Network Card.wmv

Graduation Class Lesson 2 Section 4.1: Porting the Latest u-boot – Trimming and Modifying Default Parameters.wmv

Graduation Class Lesson 2 Section 4.2: Porting the Latest u-boot – Supporting Writing YAFFS Images and Creating Patches.wmv

Chapter 15 of “Complete Manual for Embedded Linux Application Development” discusses u-boot as follows:

15.1 Introduction to Bootloaders

15.1.1 Concept of Bootloaders

15.1.2 Structure and Startup Process of Bootloaders

15.1.3 Common Bootloaders Introduction

15.2 Analysis and Porting of U-Boot

15.2.1 Introduction to U-Boot Project

15.2.2 U-Boot Source Code Structure

15.2.3 U-Boot Configuration, Compilation, and Linking Process

15.2.4 Source Code Analysis of U-Boot Startup Process

15.2.5 Porting U-Boot

15.2.6 Common Commands for U-Boot

15.2.7 Using U-Boot to Execute Programs

Learning methods are as follows:

1) First, learn from the “Writing Bootloader from Scratch” videos, which can help you understand the main functions of bootloaders with minimal code.

2) Then refer to the book for explanations of u-boot, and combine them with the “Analyzing U-Boot” videos for understanding.

3) Finally, if you have time and interest, watch the “Porting a New U-Boot” videos; this is not mandatory.

Learning level:

1) Understand the startup process of u-boot, especially the code relocation of u-boot: how it reads itself from Flash into memory.

2) Understand the core of u-boot: commands.

3) Know how the bootloader passes parameters to the kernel.

4) Know that the bootloader starts the kernel based on the command specified by “bootcmd”.

5) As an entry point: only seek understanding, not necessarily to be able to port u-boot.

2.2.8 Learning the Linux Kernel

As mentioned earlier, the kernel itself is not our main focus, but it is still necessary to understand the startup process of the kernel: you may need to modify the kernel to adapt to hardware, and knowing the startup process will tell you which files to modify.

Videos for analyzing the kernel include:

Lesson 10 Section 1: Analysis of Kernel Startup Process – Compilation Experience.wmv

Lesson 10 Section 2: Analysis of Kernel Startup Process – Configuration.wmv

Lesson 10 Section 3: Analysis of Kernel Startup Process – Makefile.wmv

Lesson 10 Section 4: Analysis of Kernel Startup Process – Kernel Startup.wmv

Videos for porting the kernel include:

Industry Class Lesson 3 Section 1: Porting Kernel 3.4.2 – Framework Introduction and Simple Modifications.wmv

Graduation Class Lesson 3 Section 2: Porting Kernel 3.4.2 – Modifying Partitions and Creating Root File System.wmv

Graduation Class Lesson 3 Section 3: Porting Kernel 3.4.2 – Supporting YAFFS File System.wmv

Graduation Class Lesson 3 Section 4: Porting Kernel 3.4.2 – Trimming and Introduction to ECC and Creating Patches.wmv

Chapter 16 of “Complete Manual for Embedded Linux Application Development” discusses the kernel as follows:

16.1 Versions and Features of Linux

16.2 Preparation for Kernel Porting

16.2.1 Obtaining Kernel Source Code

16.2.2 Kernel Source Code Structure and Makefile Analysis

16.2.3 Analysis of Kernel’s Kconfig

16.2.4 Linux Kernel Configuration Options

16.3 Linux Kernel Porting

16.3.1 Overview of Linux Kernel Startup Process

16.3.2 Modifying the Kernel to Support S3C2410/S3C2440 Development Boards

16.3.3 Modifying MTD Partitions

16.3.4 Porting YAFFS File System

16.3.5 Compiling, Burning, and Starting the Kernel

Learning methods are as follows:

1) First read the book and combine it with the “Analyzing the Kernel” videos for understanding.

2) If interested, based on the “Porting the Kernel” videos, you can master kernel porting; this is not mandatory.

Learning level:

1) Know the role of machine ID and find the corresponding files for the single board based on the machine ID.

2) Know the roles of Makefile and Kconfig, and understand how to configure the kernel simply.

3) Know how to modify partitions.

4) As an entry point: only seek understanding, not necessarily to be able to port.

2.2.9 Root File System

During the driver program development phase, we like to build a minimal root file system to debug drivers;

When developing application programs, we also need to build a file system to place various libraries and configuration files;

When releasing products, you also need to modify configuration files so that the product can automatically run programs;

Even if you want to automatically start a program after plugging in a USB drive, you need to modify configuration files;

All of this requires you to understand the composition of the root file system and understand which configuration files the kernel uses to start which application programs.

Videos for analyzing the root file system include:

Lesson 11 Section 1: Building Root File System – Starting the First Program.wmv

Lesson 11 Section 2: Building Root File System – Analyzing Init Process.wmv

Lesson 11 Section 3: Building Root File System – Busybox.wmv

Lesson 11 Section 4: Building Root File System – Constructing the Root File System.wmv

Chapter 17 of “Complete Manual for Embedded Linux Application Development” discusses the file system as follows:

17.1 Overview of Linux File System

17.1.1 Characteristics of Linux File System

17.1.2 Directory Structure of Linux Root File System

17.1.3 Introduction to Linux File Attributes

17.2 Porting Busybox

17.2.1 Overview of Busybox

17.2.2 Introduction to Init Process and User Program Startup Process

17.2.3 Compiling/Installing Busybox

17.3 Using glibc Library

17.3.1 Composition of glibc Library

17.3.2 Installing glibc Library

17.4 Constructing Root File System

17.4.1 Constructing etc Directory

17.4.2 Constructing dev Directory

17.4.3 Constructing Other Directories

17.4.4 Creating/Using YAFFS File System Image Files

17.4.5 Creating/Using JFFS2 File System Image Files

Learning methods: study in conjunction with the book and videos.

Learning level:

1) Understand the role of configuration files.

2) Know where the files in lib directory of the root file system come from.

3) Be able to create and burn file system image files.

2.3 Learning Driver Programs

There is not much discussion on driver programs in the “Complete Manual for Embedded Linux Application Development”; our released “Wei Dongshan Linux Video Series 2: On-site Writing and Debugging of Drivers” can be considered completely detached from the book.

Thus, learning driver programs can be done entirely by following the videos.

In the second phase of the videos, for each driver, we first explain the hardware principles, then write code from scratch, gradually improving its functionality.

We will not list professional terms but will refer to everyday examples, striving to use the most vivid metaphors to make it easy for you to get started while also going in-depth.

Note: We can make it easy for you to get started, but to understand deeply, you need to practice coding while following the videos; this is a process that requires careful thought and will not be easy.

If it were easy, why would you get a high salary?

Again, it is emphasized: even if you are copying, you must write code! Many people watch the videos happily, but when it comes to writing code, they are dumbfounded.

2.3.1 Classic Character Device Driver Programs

The videos take LED and button drivers as examples to explain and practice the mechanisms encountered during development: polling, sleep-wake, interrupts, asynchronous notifications, polling, synchronization, mutual exclusion, etc.

Related videos (those with “_P” in the file name belong to the second phase encrypted videos):

Lesson 12 Section 1: Character Device Driver – Concept Introduction.wmv

Lesson 12 Section 2.1: Character Device Driver – LED Driver Program: Writing and Compiling.wmv

Lesson 12 Section 2.2: Character Device Driver – LED Driver Program: Testing and Improving.wmv

Lesson 12 Section 2.3: Character Device Driver – LED Driver Program: Operating LED.wmv

Lesson 12 Section 3: Character Device Driver – Polling Method Button Driver Program.wmv

Lesson 12 Section 4.1: Character Device Driver – Interrupt Method Button Driver: Linux Exception Handling Structure.wmv

Lesson 12 Section 4.2: Character Device Driver – Interrupt Method Button Driver: Linux Interrupt Handling Structure.wmv

Lesson 12 Section 4.3: Character Device Driver – Interrupt Method Button Driver: Writing Code.wmv

Lesson 12 Section 5: Character Device Driver – Asynchronous Notification.wmv

Lesson 12 Section 6: Character Device Driver – Synchronization and Mutual Exclusion Blocking.wmv

Lesson 12 Section 7: Character Device Driver – Timer Debouncing_P.wmv

Lesson 13 Section 1: Input Subsystem Concept Introduction_P.wmv

Lesson 13 Section 2: Input Subsystem Driver Program_P.wmv

Chapter 19 of “Complete Manual for Embedded Linux Application Development” discusses character device drivers as follows:

19.1 Overview of Linux Driver Development

19.1.1 Relationship Between Application Programs, Libraries, Kernels, and Driver Programs

19.1.2 Classification and Development Steps of Linux Driver Programs

19.1.3 Loading and Unloading Driver Programs

19.2 Development of Character Device Drivers

19.2.1 Important Data Structures and Functions in Character Device Drivers

19.2.2 Analysis of LED Driver Program Source Code

Chapter 20 discusses the Linux Exception Handling Architecture:

20.1 Overview of Linux Exception Handling Architecture

20.1.1 Hierarchical Structure of Linux Exception Handling

20.1.2 Common Exceptions

20.2 Linux Interrupt Handling Architecture

20.2.1 Initialization of Interrupt Handling Architecture

20.2.2 Process of User Registering Interrupt Handling Functions

20.2.3 Process of Interrupt Handling

20.2.4 Unloading Interrupt Handling Functions

20.3 Example of Driver Programs Using Interrupts

20.3.1 Analysis of Button Driver Program Source Code

20.3.2 Testing Program Scenario Analysis

Learning methods:

1) Follow the data flow direction and analyze the scenario from the application program’s use of the driver program.

Scenario analysis means assuming that the application program initiates a certain operation, and you analyze the operation process involved. For example, when the application program calls open, read, ioctl, etc., which driver functions are involved.

You need to think about one question: how does an application program obtain button information, and how does it control the LED? Once you clarify the data flow, you will have a basic understanding of character device drivers.

2) When learning exceptions and interrupts, you can combine the book and videos; for learning other content in driver programs, you may not need to read the book.

2.3.2 Various Driver Programs in Work

Our videos cover many driver programs for two purposes:

1) To provide references for similar drivers you may encounter in your work.

2) To provide learning and practice opportunities to refine your reading “sense” of driver programs, improve your programming skills, and gain debugging experience.

We also plan to expand the driver videos and turn them into a “Complete Linux Driver Program” video series, primarily adopting an approach of writing from scratch on-site.

Some may say: in work, we primarily just port or modify drivers, rarely writing from scratch. This is correct, but the premise for modification is understanding; to understand better, the best method is to write one from scratch. In the learning stage, do not be afraid of spending too much time writing from scratch and gradually improving it; in this process, you will understand the driver and refine your skills, achieving a broader understanding.

If you have time, it is recommended that you learn all these videos until you feel:

1) If given a new board, you can quickly implement the relevant driver.

2) If given new hardware, you can quickly write/port the driver for it.

We have recorded many videos; below is a list up to the “lesson” level, without listing the “section” level.

Second Phase Videos:

Lesson 14: Concept of Layered Separation in Driver Programs – Bus Driver Device Model

Lesson 15: LCD Driver Program

Lesson 16: Touchscreen Driver Program

Lesson 17: USB Driver Program

Lesson 18: Block Device Driver Program

Lesson 19: NAND FLASH Driver Program

Lesson 20: NOR FLASH Driver Program

Lesson 21: Network Card Driver Program

Lesson 22: Porting DM9000C Driver Program

Lesson 23: I2C Device Bare-board Program

Lesson 24: I2C Driver Program (Do not watch this lesson; watch Lesson 32 instead, which is better).

Lesson 26: Sound Card Driver Program (Do not watch this lesson; watch the ALSA driver in the third phase instead, which is better).

Lesson 27: DMA Driver Program

Lesson 28: Hotplug_Uevent Mechanism

Lesson 32: I2C Driver Program under Kernel 3.4.2

Third Phase Driver Videos:

Camera Driver – Virtual Driver Vivi

Camera Driver – USB Camera

Camera Driver – CMOS Camera

WIFI Network Card Driver Porting

3G Network Card Driver Porting

ALSA Sound Card Driver Program

Learning methods:

1) It is emphasized again: you cannot just watch without practicing; you must write programs, even if copying.

2) Must learn: LCD, touchscreen, NAND Flash, NOR Flash, hotplug_uevent mechanism.

3) After learning, it is strongly recommended to switch to a different development board and try writing driver programs on the new board.

Following the videos will lead to smooth learning; many problems you may not have thought of will surface, and switching to a new board will truly help you master the concepts.

2.3.3 Debugging Methods

There is a saying that programming is 30% writing and 70% debugging. We provide some very useful debugging methods from the perspective of the operating system.

Related posts

Leave a Comment Cancel reply