Note-taking-for-Newifi2-D1-MTD

Hardware:Newifi2 D1
Bootloader:Breed written by hackpascal

Definition of MTD(Memory Technology Device)

A type of device file in Linux for interacting with flash memory. The MTD subsystem was created to provide an abstraction layer between the hardware-specific device drivers and higher-level applications.

Differences

Linux traditionally only knew block devices and character devices. Character devices were things like keyboards or mice, that you could read current data from, but couldn’t be seek-ed and didn’t have a size. Block devices had a fixed size and could be seek-ed. They also happened to be organized in blocks of multiple bytes, usually 512.

USB sticks, MMCs, SDs, CompactFlashes and other popular removable devices should not be confused with MTDs. Although they contain flash memory, this is hidden behind a block device interface using a FTL(Flash Translation Layer).

Based on how the flash memory chip is connected with the SoC (i.e. the “host”) OpenWrt distinguish between raw flash or host-managed and FTL (Flash Translation Layer) flash or self-managed: in case the flash memory chip is connected directly with the SoC we call it raw flash or host-managed and in case there is an additional controller chip between the flash memory chip and the SoC, we call it FTL flash or self-managed. Primarily the controller chip does wear-leveling and manages known bad blocks, but it may do other stuff as well. The flash memory cannot be accessed directly, but only through this controller. The controller has to be considered a black box.

The following table describes the differences between block devices and raw flashes. Note, SSD, MMC, eMMC, RS-MMC, SD, mini-SD, micro-SD, USB flash drive, CompactFlash, MemoryStick, MemoryStick Micro, and other FTL devices are block devices, not raw flash devices. For example, if you look inside an USB flash drive, you’ll find there a NAND chip (or several of them), and a micro-controller, which runs FTL firmware. Some USB flash drives are known to have quite powerful ARM processors inside. Similarly, MMC, eMMC, SD, SSD, and other FTL devices have a built-in controller which runs FTL firmware.

Block device MTD device
Consists of sectors Consists of eraseblocks
Sectors are small (512, 1024 bytes) Eraseblocks are larger (typically 128KiB)
Maintains 2 main operations: read sector and write sector Maintains 3 main operations: read from eraseblock, write to eraseblock, and erase eraseblock
Bad sectors are re-mapped and hidden by hardware (at least in modern LBA hard drives); in case of FTL devices it is the responsibility of FTL to provide this Bad eraseblocks are not hidden and should be dealt with in software
Sectors are devoid of the wear-out property (in FTL devices it is the responsibility of FTL to provide this) Eraseblocks wear-out and become bad and unusable after about 103 (for MLC NAND) - 105 (NOR, SLC NAND) erase cycles

Flash doesn’t match the description of either block or character devices. They behave similar to block device, but have differences. For example, block devices don’t distinguish between write and erase operations. Therefore, a special device type to match flash characteristics was created: MTD.

So MTD is neither a block nor a char device. There are translations to use them, as if they were. But those translations are nowhere near the original, just like translated Chinese poems.

When using an MTD, the use of an MTD aware file system such as JFFS2 or YAFFS is recommended. The MTD subsystem exports block devices as well, which allows the use of common filesystem like ext4.

Newifi2 D1 as an example

1
2
3
4
5
6
7
8
9
10
11
cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "Factory"
mtd3: 02000000 00010000 "fullflash"
mtd4: 01fb0000 00010000 "firmware"
mtd5: 0012b360 00010000 "kernel"
mtd6: 01e64ca0 00010000 "rootfs"
mtd7: 01070000 00010000 "rootfs_data"
mtd8: 00020000 00010000 "panic_oops"

The dts description for Newifi2 D1 also can be found at git.openwrt.org.
ramips: fix support for MX25L25635F flash

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
m25p80@0 {
compatible = "mx25l25635f", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <25000000>;
m25p,fast-read;

partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

partition@0 {
label = "u-boot";
reg = <0x0 0x30000>;
read-only;
};

partition@30000 {
label = "u-boot-env";
reg = <0x30000 0x10000>;
read-only;
};

factory: partition@40000 {
label = "factory";
reg = <0x40000 0x10000>;
read-only;
};

partition@50000 {
compatible = "denx,uimage";
label = "firmware";
reg = <0x50000 0x1fb0000>;
};
};

The hierarchy of flash storage partitions:

From the hierarchy diagram, it’s very clear why the following commands are used to write flash.

1
2
3
4
5
6
7
8
9
10
11
#BACKUP
cd /tmp
dd if=/dev/mtd0 of=uboot.bin
dd if=/dev/mtd2 of=factory.bin
dd if=/dev/mtd3 of=fullflash.bin

#WRITE FLASH
dd if=/dev/zero bs=1024 count=192 | tr "\000" "\377" >breed_192.bin
dd if=breed-mt7621-newifi-d1.bin of=breed_192.bin conv=notrunc
cat /tmp/breed_192.bin /dev/mtd1 /dev/mtd2 /dev/mtd4 >fullflash_with_breed.bin
mtd write fullflash_with_breed.bin fullflash

!

Please point out if there is a miscalculation or misunderstanding, thanks.

REF

Comments

You forgot to set the shortname for Disqus. Please set it in _config.yml.