Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the concept of linux mtd". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what is the concept of linux mtd"?

In linux, mtd refers to "memory technology device", which is a subsystem of storage device. Linux introduced MTD system to provide a unified interface for NOR FLASH and NAND FLASH devices. MTD devices are usually divided into four layers: device node, MTD device layer, MTD original equipment layer, and hardware driver layer.

The operating environment of this tutorial: linux5.9.8 system, Dell G3 computer.

What is Linux MTD?

The full name of MTD is "Memory Technology Device", which means "memory technology device". It is a subsystem of Linux's storage device.

In the Linux kernel, the MTD layer is introduced to provide a unified interface for NOR FLASH and NAND FLASH devices. MTD isolates the file system from the underlying FLASH memory.

The purpose of designing this MTD system is to provide an abstraction layer and an interface for memory devices, so that for hardware driver designers, it is only necessary to provide the simplest read / write / erase functions of the underlying hardware devices. How the data is represented for the upper users can be ignored, because the MTD storage device subsystem has done it for you.

MTD framework

The MTD device for Linux is located under drivers/mtd/.

The contents under the MTD file are as follows:

MTD devices can usually be divided into four layers

From top to bottom are: device node, MTD device layer, MTD raw equipment layer and hardware driver layer.

1.cmdlinepart.c

When the mtd partition table is transferred from u-boot to linux through the cmd parameter, the linux kernel does not need to register and add mtdparts, but only needs to turn on the command line partition option in MTD. Using this method, MTD needs to be supported under u-boot, and the transmitted mtd partition parameters should meet the format requirements.

2.devices folder

When we have a spi flash device and use mtd to manage it, we usually put it under the devices folder. For example, m25p80.c under the devices folder is a typical spi flash device.

3.chips/nand/onenand folder

The nand flash driver is under the nand folder.

The onenand flash driver is under the onenand folder.

Nor flash is rather complicated, which can be found in the following files:

Chips:cfi/jedec interface universal driver

Devices:nor flash underlying driver (spi flash)

Maps:nor flash mapping relation correlation function

4. Core document

Mtdchar.c: implementation of MTD character device interface, device number 31

Mtdblock.c: MTD block device interface related implementation, device number 90

Mtdcore.c: related implementation of MTD original device interface

Mtdpart.c: related implementation of MTD partition interface.

5.ubi

For the support layer of ubifs files, you need to select Enable UBI in Device Drivers-> Memory Technology Device (MTD) support-> UBI-Unsorted block image when using the ubifs file system.

Select UBIFS filesystem support in File systems-> Miscellaneous filesystems.

Implementation of MTD Partition Table

During the boot process, you can often see information similar to the following from console

0x000000000000-0x000000100000: "Bootloade" 0x000000100000-0x000002000000: "Kernel" 0x000002000000-0x000003000000: "User" 0x000003000000-0x000008000000: "File System"

This is where MTD gives us the most intuitive representation, showing us the partition structure of each module in memory, but how are these partitions implemented? There are several ways to implement a partition table, which are described below:

Note: the premise of the partition table implementation is that the MTD device driver has been successful, otherwise there will be no partition if the driver is not successful.

1. Add to the kernel

Adding this to the kernel is a frequently used method, which should be found in any driver porting book. The main thing is to add mtd_partition to the platform device and add information similar to the following, which is not described too much here.

Struct mtd_partition s3c_nand_part [] = {{.name = "Bootloader", .offset = 0, .size = (1 * SZ_1M), .mask _ flags = MTD_CAP_NANDFLASH,}, {.name = "Kernel", .offset = (1 * SZ_1M), .size = (31 * SZ_1M) .mask _ flags = MTD_CAP_NANDFLASH,}, {.name = "User", .offset = (32 * SZ_1M), .size = (16 * SZ_1M),}, {.name = "File System", .offset = (48 * SZ_1M), .size = (96 * SZ_1M) }} Static struct s3c_nand_set s3c_nand_sets [] = {[0] = {.name = "nand", .nr _ chips = 1, .nr _ partitions = ARRAY_SIZE (s3c_nand_part), .partitions = ok6410_nand_part,},} Static struct s3c_platform_nand s3c_nand_info = {.tacls = 25, .twrph0 = 55, .twrph2 = 40, .nr _ sets = ARRAY_SIZE (s3c_nand_sets), .sets = ok6410_nand_sets,}; static void _ init s3c_machine_init (void) {s3c_nand_set_platdata (& s3c_nand_info);}

Because our MTD driver has been completed, the probe interface function in the driver will be called when device and driver match. We need to call add_mtd_partitions (s3c_mtd, sets- > partitions, sets- > nr_partitions) in the probe function to add the partition table.

2.u-boot parameter transfer

Under u-boot, you can add mtdparts information to bootargs. After u-boot starts, the information in bootargs will be transmitted to kernel,kernel and the mtdparts part of bootargs will be parsed at startup. Here is an example:

Mtdparts=nand.0:1M (Bootloader) ro,31M (Kernel) ro,16M (User), 96m (File System), more specific mtdparts format can consult the relevant information.

In order for kernel to parse mtdparts information, we need to turn on the Device Drivers-> Memory Technology Device (MTD) support-> Command line partition table parsing option in the kernel, as mentioned above.

When we add partition tables to the kernel, we add mtd_partition information to the platform devices. Passing parameters through u-boot here cancels the partition information in the platform device, so how do we analyze the mtdparts passed by u-boot?

After the parameters are passed by u-boot, these parameters will be parsed in cmdlinepart.c and stored in the LIST_HEAD (part_parsers) linked list, and then we will call the mtd_device_parse_register (mtd, probe_types,&ppdata, NULL, 0); function in the driven probe function.

The mtd_device_parse_register () function is located in drivers/mtd/mtdcore.c and contains the following:

Int mtd_device_parse_register (struct mtd_info * mtd, const char * const * types, struct mtd_part_parser_data * parser_data, const struct mtd_partition * parts, int nr_parts) {int err; struct mtd_partition * real_parts; err = parse_mtd_partitions (mtd, types, & real_parts, parser_data) If (err 0) {err = add_mtd_partitions (mtd, real_parts, err); kfree (real_parts);} else if (err = = 0) {err = add_mtd_device (mtd); if (err = = 1) err =-ENODEV;} return err;}

You can see that the function first executes the parse_mtd_partitions (mtd, types, & real_parts, parser_data); function, followed by the add_mtd_partitions () function to add the partition table.

The parse_mtd_partitions () function is located in drivers/mtd/mtdpart.c and contains the following:

Int parse_mtd_partitions (struct mtd_info * master, const char * const * types, struct mtd_partition * * pparts, struct mtd_part_parser_data * data) {struct mtd_part_parser * parser; int ret = 0; if (! types) types = default_mtd_part_types; for (; ret parse_fn) (master, pparts, data); put_partition_parser (parser) If (ret > 0) {printk (KERN_NOTICE "% d% s partitions found on MTD device% s\ n", ret, parser- > name, master- > name); break;}} return ret;}

Entering the parse_mtd_partitions () function will first determine the type of types. If it is empty, the default value will be given. Generally speaking, there are two types of types, as follows:

Static const char * const default_mtd_part_types [] = {"cmdlinepart", "ofpart", NULL}

The first "cmdlinepart" is the way u-boot passes parameters, and the second "ofpart" is the way to use dts to pass parameters. After judging the type, you will parse the data in the part_parsers linked list through get_partition_parser, thus completing the parsing of u-boot parameters.

3.dts parameter transfer

In the later linux version of Linux3.14, a new knowledge DTS (Device tree) is added. Dts is actually to solve the redundant code in ARM Linux. There is a lot of junk code in arch/arm/plat.xxx and arch/arm/mach.xxx of Linux2.6 version. After adopting Device Tree, many hardware details can be passed to Linux directly through it, instead of a lot of redundant coding in kernel. About dts, you can consult the data on your own.

The principle of dts parameter transfer is the same as that of u-boot. The difference is that when u-boot, partition information is written into LIST_HEAD (part_parsers) linked list through cmdlinepart.c file, while dts uses ofpart.c file to write partition information into LIST_HEAD (part_parsers) linked list, so it is also necessary to open the macro of ofpart.c file and call mtd_device_parse_register (mtd, probe_types,&ppdata, NULL, 0). Function, types should be set to ofpart.

If you compare the Linux2.6 version and the Linux3.14 version, you will find that the drivers/mtd/ofpart.c and drivers/mtd/mtdpart.c files are different. There is more Device tree in the Linux3.8 version, and those who are interested can delve into it themselves.

Here's an example of dts:

Pinctrl-0 =; ranges =; / * CS0: NAND * / nand@0,0 {partition@1 {label = "Bootloader"; reg =;}; partition@2 {label = "Kernel"; reg =;}; partition@3 {label = "User"; reg =;} Partition@4 {label = "File System"; reg =;};}; at this point, I believe you have a deeper understanding of "what is the concept of linux mtd", you might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.