Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you the analysis process of powering up the i.MX6UL chip in the porting and development of embedded Linux system. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Analysis of Power-up process of i.MX6UL Chip

Porting and Development of embedded Linux system-Building embedded u-boot, Kernel and File system based on Yocto

Before analyzing the u-boot startup process of i.MX6UL, let's first analyze what operations were performed and what processing was carried out when the i.MX6UL chip was powered on. This power-up process usually refers to the process from the power-on of the processor chip to the execution of the assembly entry function to BootLoader (for example, the entry function of u-boot is the _ start function).

Many beginners or part of MCU engineers will think that when the chip is powered on, the first program to execute is a BootLoader like u-boot, or a startup file similar to xxxx_start_up.S in the MCU program, and many MCU engineers think that the chip will execute the main () function as soon as it is powered on. In fact, when most embedded processor chips are powered on, the first thing to execute is neither BootLoader nor boot files similar to xxxx_start_up.S. Instead, it executes a program that developers can't see or touch, which is often called BootROM. This program is fixed in the chip by the chip designer during the production and design of the embedded processor chip. as the role of using the chip, the developer does not need to obtain the BootROM source code or rewrite the BootROM source code. But as a development engineer, if you understand the working principle of BootROM, you can have a deeper understanding of the startup process of chip power-up.

Let's take a look at the on-chip flow of i.MX6UL, as shown in the following figure:

The main results are as follows: (1) after the chip power-on reset is started, the CPU_ID is detected first, and then the type of reset is detected.

(2) there are two main types of reset startup: normal startup mode and low power startup mode.

(3) if booting from low-power mode, the chip will first detect whether wake-up is allowed, if not, the chip will clear the low-power state and then reset. If so, the wake-up process is performed and the execution is redirected to a valid mirror.

(4) if it is in normal startup mode, the startup mode will be decided according to the status of eFUSES or GPIO pins. There are three startup modes: starting from eFUSES, starting from Serial Downloader, and starting from Internal Boot. These three startup modes will be explained later.

(4.1) if you enter Serial Downloader to start, the image will be downloaded and verified by USB.

(4.2) eFUSES startup and Internal Boot startup are actually similar, except that the startup mode of eFUSES cannot be rewritten by GPIO pins. Internal Boot startup can change different startup modes according to GPIO pins. The startup mode also needs to be judged with BT_FUSE_SEL.

(4.3) if Internal Boot boot is selected through the GPIO pin, the boot image is loaded from the external device, and if the image load is successful, the loaded boot image (usually u-boot) is executed. If loading the image fails, jump to Serial Downloader startup and download the boot image via USB.

Generally speaking, the main function of the BootROM of the i.MX6UL chip is to determine where the chip loads the boot image (which can be SD card, NandFlash,eMMC, etc.) according to the status of the internal eFUSES or external GPIO, and then obtain the initialization mode of the chip from the boot image (boot image u-boot.imx is the collection of u-boot.bin + header data, which is provided to the chip's BootROM). Finally, through the absolute address, jump to the boot image and execute the first user program instruction (usually the _ start function in u-boot. Through the u-boot.lds link script, you can see the first function entry of u-boot, followed by the startup process of u-boot).

For low-power mode startup, this chapter does not analyze, this chapter focuses on the analysis of Normal Boot startup mode, that is, normal mode startup, in Normal Boot startup mode, there are three main startup modes: from eFUSES startup, into Serial Downloader startup, into Internal Boot startup. These three startup modes are mainly determined by the BOOT_MODE [1:0] register and the eFUSES flag BT_FUSE_SEL. The truth tables for BOOT_MODE [1:0] and BT_FUSE_SEL are as follows:

For debugging environments, BOOT_MODE [1:0] = 10 and BT_FUSE_SEL = 1 are usually used for configuration, making it easy for developers to debug. For production environments, BOOT_MODE [1:0] = 00 and BT_FUSE_SEL = 1 are usually used for configuration, and debugging is no longer allowed on the chip, booting from boot_device every time you power on. (here boot_device refers to NandFlash, SD card, eMMC and other devices that store boot image.) the chip has three external pins: BOOT_MODE0, BOOT_MODE1, and POR_B. The state of these two pins will be captured on the rising edge of the POR_B pin, and then the status of these two pins will be recorded in the two bits of BMOD [1:0] in the SRC_SBMR2 register. The state of the subsequent two pins no longer affects the BOOT_MODE register inside the chip.

The two startup methods of "starting from eFUSES" and "starting into Internal Boot" are similar, except that Internal Boot startup can override the value of eFUSES through some GPIO, so Internal Boot startup is used more when debugging with the development board. For the author to write this chapter using the development board is TQ-i.MX6UL, the core board of this development board is to use 256MB NandFlash, the development board also supports SD card startup and burning system image, so, later to analyze, i.MX6UL uses NandFlash as the boot_device startup process.

When the i.MX6UL chip starts through NandFlash, because BootRom does not know the specific NandFlash model, BootRom will communicate with NandFlash in a general but not optimal communication timing and read a boot control block (Boot Control Blocks, referred to as BCB) from NandFlash. This boot control block contains two data structures: firmware control block (FCB) and bad block table (Discovered Bad Block Table, DBBT).

The FCB firmware control block is protected by the NandFlash hardware ECC to ensure the correctness of the FCB. As soon as the chip is powered on, BootRom reads 2112 bytes of the first page of the NandFlash's first block (2048 bytes of page size + 64 bytes of spare space). If these 2112 bytes are not valid FCB data, it will continue to jump to find the next FCB data. If the maximum number of searches has not been found, the NandFlash driver in BootRom will respond to an error and let the chip enter Serial Downloader mode to start.

If a valid FCB is found, because the FCB contains the address page information of the DBBT, BootRom will look up the DBBT according to the address in the FCB. If the search area for DBBT in FCB is 0, there are no bad blocks in the NandFlash.

Data structure about FCB firmware control blocks and DBBT bad block tables. The data structure of the FCB firmware control block, as shown in the following figure:

The data structure of DBBT bad block table contains the following information: DBBT fingerprint information, version number, size of DBBT bad block table, number of bad blocks, number of bad blocks, and so on.

To sum up: FCB and DBBT are located at the beginning of NandFlash, and the contents of these two data structures are read by BootROM when the chip is powered on. FCB contains the best working timing of NandFlash and the starting page address of the first boot firmware (in this case, it refers to the storage page address of u-boot.imx). BootRom will initialize the NandFlash through the best working sequence of NandFlash, find out where the u-boot.imx is stored, and start parsing the Header header data of u-boot.imx after loading u-boot.imx.

We downloaded the u-boot file to the development board, the full name is "u-boot.imx", this file is a collection of u-boot.bin and some Header header data. These Header header data are generated by the mkimage tool calling an interpreter of format type imximage when compiling u-boot. Mkimage packages these header data with u-boot.bin into a u-boot.imx format file. This u-boot.imx file is called Program Image in the manual.

Program Image, or u-boot.imx, includes the following aspects:

(1) Image Vector Table-Mirror Vector Table, or IVT for short, is located in the pointer list of fixed addresses, and ROM checks the list to determine the location of other components of the program image.

(2) Boot Data-indicates the location, size, and plug-in flag of the program image.

(3) Device Configuration Data-represents the initialization data of the chip IC.

(4) User Code and Data-user code and data

The memory diagram of Program Image (that is, u-boot.imx) is shown below:

For the TQ-i.MX6UL development board, the hexadecimal data and analysis of the supporting u-boot.imx file are shown in the following figure:

I.MX6UL uses NandFlash as the startup device, and the power-up process is summarized as follows:

The BootRom program in the chip will determine whether the chip starts from NandFlash through the internal boot mode according to the state of the external BOOT_MODE [1:0] pin. The FCB and DBBT needed for startup are stored in the first 4k space of NandFlash. By reading FCB and DBBT, you can get the best working timing of NandFlash, the condition of bad block table, and the location of u-boot.imx in NandFlash. U-boot.imx is actually a collection of u-boot.bin plus Header data. When the location of the u-boot.imx is known, the first 2k bytes of the u-boot.imx are copied to the chip's internal RAM for parsing, but cannot be copied to the external RAM, because the external RAM has not been initialized at this time. These 2K bytes are IVT information, BootData information, DCD information. Among them, the IVT message contains the link address of u-boot.bin, which allows the chip to jump to the u-boot program and begin to execute the first program statement of u-boot.

The above is the analysis process of power-on of i.MX6UL chip in embedded Linux system porting development shared by Xiaobian. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.