Understanding of MTD partition and uboot partition in NAND Flash

 

During kernel transplantation today, we are going to add the NAND Flash Driver to achieve MTD partitioning. When we think of a sentence we saw in a book, we say there is no gap between each partition during partitioning, the ending address of the previous area is the starting address of the next area. However, when I look at my Development Board tutorial, the partition is as follows:

Static struct mtd_partition smdk_default_nand_part [] = {

[0] = {

. Name = "uboot ",

. Offset = 0x00000000,

. Size = 0x00040000,

},

[1] = {

. Name = "kernel ",

. Offset = 0x00200000,

. Size = 0x00300000,

},

[2] = {

. Name = "yaffs2 ",

. Offset = 0x00500000,

. Size = mtdpart_siz_full

}

};

Obviously, there is a gap between the uboot and the kernel partitions, and I am wondering, do you need to pay attention to the MTD partition? Find the reason by searching for information and reading books. Correct the error.

 

First, let's talk about how the Linux SSD (one of which is nand flash) arranges system components.

 

Bootstrap loader

Bootstrap Parameters

Kernel

Root file system

 

That is to say, in NAND Flash, each part of the program is arranged in this way, but which end is the high address varies according to the architecture. For arm, the boot loader is at the lowest address. Therefore, no matter whether it is a uboot partition or a kernel MTD partition, the partitions of the boot loader are at the lowest address. So how do we associate the two partitions, and how do we set MTD partitions? First, the partition information of the uboot Development Board is provided:

 

Bootargs = noinitrd root =/dev/mtdblock2 init =/linuxrc console = ttysac0

Mtdparts = nandflash0: 256k @ 0 (BiOS), 128 K (Params), 128 K (TOC), 512 K (eboot), 1024 K (logo ), 3 M (kernel),-(Root)

 

Next, let's talk about the MTD partition, which is a partition that can be identified by the kernel. That is to say, kernel operations are based on MTD partitions. The uboot partition is only for convenient operations, for example, I want to write the content in the memory 0x30000000 address to the address with a 2 m offset from the NAND Flash, that is, the starting position of the kernel in the uboot partition. In general, we need to write

Nand write 0x30000000 0x00200000

However, if you have a uboot partition, you can write

Nand write 0x30000000 Kernel

 

To further elaborate on the subsequent issues, I would like to explain my understanding of the uboot boot process. After the system is started, uboot starts to run and completes the work in two phases, it mainly involves initialization, loading the kernel, passing kernel parameters, and then jumping into the kernel for execution. The kernel completes its initialization, including mounting the file system.

 

Now, we can look back at the MTD partition in the above program. The uboot partition in the MTD partition clearly corresponds to the BIOS partition in the uboot partition (starting from 0, with a size of 128 K ), the start address and size of the kernel and yaffs2 partitions in the MTD partition correspond to the kernel and root partitions in the uboot partition respectively. Because we do not need other parts of the uboot partition, this part of the gap occurs in the MTD partition. But why?

 

Recall the operations we performed when burning the program. For example, if we chose to burn the kernel image, uboot actually runs a statement, which is similar

 

# Define kernel 0x00200000

Memcpy (kernel, 0x30000000, sz_3m)

 

Here, the entry address of the program is 0x30000000. That is to say, the uboot download mode writes the data written to the memory 0x30000000 and moves it to the kernel of the NAND Flash, saved,Therefore, it should be clear that when we burn a program, the program is actually first written to the memory, and then moved from the memory to the NAND Flash,If our MTD partition is the same as that in uboot at this time, you can easily find the location of the kernel program when the kernel runs in the future. Similarly, the same applies to the yaffs2 partition of the file system. In addition, the partition of the file system is more important than that of the kernel partition, because it directly affects whether the root file system can be mounted, this is because the line mentioned above

 

Bootargs = noinitrd root =/dev/mtdblock2 init =/linuxrc console = ttysac0

 

Here, uboot specifies that the code of the root file system comes from mtdblock2, that is, the third partition of the MTD partition (the first Partition Number is 0), that is, what I mentioned above, after uboot Initialization is complete, it loads the kernel, and the kernel needs to mount the file system. Where does it find the file system? That's it! /Dev/mtdblock2!

So now we can see the MTD partition reason, and the most important thing is that if the partitions of other partitions are inconsistent with those of uboot, however, if the file system partition in the MTD partition is inconsistent with the root partition in uboot, the system cannot be started!

Of course, the previous operations are all physical addresses. When the kernel is actually running, virtual addresses will be used.

Similarly, the system can run normally only when several other boot parameters are satisfied.

Init =/linuxrc INIT process location.

Console = ttysac0 corresponds to the tty device. Therefore, the serial port driver porting should be completed before the boot system.