As a leading programmer manufacturer in the industry, Ontech (stock code: 873207) has taken the lead in in-depth cooperation with the excellent domestic chip manufacturers Allwinner Technology and MediaTek, and supports the offline programming of the UBI file system developed by Allwinner, which greatly improves The production and burning efficiency of smart speakers; in Acroview manual burner AP8000, high-quality automatic burner IPS7000, cost-effective EAP3000, EAP5000, it fully supports burning Allwinner R328, MTK MediaTek MTK8516, MTK8167 smart speaker Nand Flash programming algorithm;

图一：AP8000

Introduction to UBI File System

Before linux-2.6.27, when it comes to Flash file systems, many people often think of file systems such as cramfs, jffs2, and yaffs2. They are also based on the file system+mtd+flash device architecture. After linux-2.6.27, the kernel added a new type of flash file system UBI (Unsorted Block Images). Here is a brief introduction to the reason why the UBI file system is added and how to use it. I am also new to this file system, and there may be some misunderstandings. Please correct me.

1. Background

FLASH has the characteristics of "erase and then write", bad blocks, and "limited number of reads and writes". The current methods for managing FLASH mainly include:

1. Adopt MTD+FTL/NFTL (flash conversion layer/nand flash conversion layer) + traditional file system, such as FAT, ext2, etc. The use of FTL/NFTL is aimed at the unique attributes of FLASH, and realizes log management, bad block management, profit and loss balance and other technologies through software. However, practice has proved that this program has certain limitations due to various factors such as intellectual property rights and efficiency.

2. Using the hardware translation layer + traditional file system. This method is adopted by many memory card products, such as SD cards, U disks, etc. For some products, this solution has a higher cost.

3. Use MTD+ FLASH special file system, such as JFFS1/2, YAFFS1/2, etc. They greatly improve the management ability of FLASH and are widely used.

JFFS2, YAFFS2 and other special file systems also have some technical bottlenecks, such as high memory consumption, linear dependence on FLASH capacity, file system size, content, access mode, etc., poor profit and loss balance ability or transitional profit and loss. In this context, the kernel has added support for the UBI file system.

Two, usage

Environment: omap3530 processor, (128MByte 16-bit NAND Flash), linnux-2.6.28 kernel

1. Configure the kernel to support UBIFS

   Device Drivers --->Memory Technology Device (MTD) support --->UBI-Unsorted block images --->Enable UBI

       Configure mtd to support UBI interface

       File systems --->Miscellaneous filesystems --->UBIFS file system support

       Configure the kernel to support UBIFS file system

2. Mount an MTD partition 4 as UBIFS format

   ● flash_eraseall /dev/mtd4 //erase mtd4

       ● ubiattach /dev/ubi_ctrl -m 4 //Associated with mtd4

       ● ubimkvol /dev/ubi0 -N rootfs -s 100MiB //Set the volume size (not a fixed value, you can change it with tools) and name

       ● mount -t ubifs ubi0_0 /mnt/ubi or mount -t ubifs ubi0:rootfs /mnt/ubi

3. Make UBIFS file system

When making a UBI image, you need to determine the following parameters:

   MTD partition size; //The corresponding FLASH partition size

       flash physical eraseblock size; // FLASH physical erase block size

       minimum flash input/output unit size; //Small FLASH input and output unit size

       for NAND flashes-sub-page size; //For NAND flash, the sub-page size

       logical eraseblock size.//logical erase block size

Parameters can be obtained in several ways

1) If you are using a kernel after 2.6.30, this information can be obtained from the kernel through tools, such as: mtdinfo -u.

2) The previous kernel can use the following methods:

   ● MTD partition size: Obtained from the kernel partition table or cat /proc/mtd

       ● flash physical eraseblock size: you can get the FLASH physical erase block size from the flash chip manual, or cat /proc/mtd

       ● minimum flash input/output unit size:

           1) nor flash: usually 1 byte

           2) nand falsh: a page

       ● sub-page size: obtained through flash manual

       ● Logical eraseblock size: For NAND FLASH with subpages, it is equal to "physical erase block size-1 page size"

3) It can also be obtained through the information generated when ubi and mtd are connected, such as:

#modprobe ubi mtd=4 //ubi is loaded as a module

or

#ubiattach /dev/ubi_ctrl -m 4 //Associate MTD through ubiattach

    UBI: attaching mtd4 to ubi0

    UBI: physical eraseblock size: 131072 bytes (128 KiB)

    UBI: logical eraseblock size: 129024 bytes

    UBI: smallest flash I/O unit: 2048

    UBI: sub-page size: 512

    UBI: VID header offset: 512 (aligned 512)

    UBI: data offset: 2048

    UBI: attached mtd4 to ubi0

For a more detailed explanation, see http://www.linux-mtd.infradead.org/doc/ubi.html#L_overhead

#mkfs.ubifs -r rootfs -m 2048 -e 129024 -c 812 -o ubifs.img

    #ubinize -o ubi.img -m 2048 -p 128KiB -s 512 /home/lht/omap3530/tools/ubinize.cfg

-r: specify the location of the file content

    -m: page size

    -e: logical erase block size

    -p: physical erase block size

    -c: Number of large logical erase blocks

    In our case, the file system can access 129024*812=100M space on the volume.

    -s: Small hardware input and output page size, such as 256 for k9f1208 (upper and lower half page access)

Among them, the content of ubinize.cfg is:

[ubifs]

    mode=ubi

    image=ubifs.img

    vol_id=0

    vol_size=100MiB

    vol_type=dynamic

    vol_name=rootfs

    vol_flags=autoresize

4. Use uboot to burn and start UBIFS image

1) Burn UBIFS image

OMAP3 DevKit8000 # mmcinit

    OMAP3 DevKit8000 # fatload mmc 0:1 81000000 ubi.img

    reading ubi.img

    12845056 bytes read

    OMAP3 DevKit8000 # nand unlock

    device 0 whole chip

    nand_unlock: start: 00000000, length: 268435456!

    NAND flash successfully unlocked

    OMAP3 DevKit8000 # nand ecc sw

    OMAP3 DevKit8000 # nand erase 680000 7980000

    NAND erase: device 0 offset 0x680000, size 0x7980000

    Erasing at 0x7fe0000 - 100% complete.

    OK

    OMAP3 DevKit8000 # nand write.i 81000000 680000 $(filesize)

    NAND write: device 0 offset 0x680000, size 0xc40000

    Writing data at 0x12bf800 - 100% complete.

    12845056 bytes written: OK

The process of burning and writing the kernel image is the same, so the UBI file system should not use the OOB area of nand like the yaffs file system.

2) Set the UBIFS file system as the boot parameter of the root file system

OMAP3 DevKit8000 # setenv bootargs console=ttyS2,115200n8 ubi.mtd=4 root=ubi0:rootfs

    rootfstype=ubifs video=omapfb:mode:4.3inch_LCD

    OMAP3 DevKit8000 # setenv bootcmd nand read.i 80300000 280000 200000;bootm 80300000

The location of the root file system is on MTD4

When the system starts, it will print out the following information related to UBI:

Creating 5 MTD partitions on'omap2-nand':

    0x00000000-0x00080000:'X-Loader'

    0x00080000-0x00260000:'U-Boot'

    0x00260000-0x00280000:'U-Boot Env'

    0x00280000-0x00680000:'Kernel'

    0x00680000-0x08000000:'File System'

    UBI: attaching mtd4 to ubi0

    UBI: physical eraseblock size: 131072 bytes (128 KiB)

    UBI: logical eraseblock size: 129024 bytes

    UBI: smallest flash I/O unit: 2048

    UBI: sub-page size: 512

    UBI: VID header offset: 512 (aligned 512)

    UBI: data offset: 2048

    UBI: attached mtd4 to ubi0

    UBI: MTD device name:'File System'

    UBI: MTD device size: 121 MiB

    UBI: number of good PEBs: 970

    UBI: number of bad PEBs: 2

    UBI: max. allowed volumes: 128

    UBI: wear-leveling threshold: 4096

    UBI: number of internal volumes: 1

    UBI: number of user volumes: 1

    UBI: available PEBs: 0

    UBI: total number of reserved PEBs: 970

    UBI: number of PEBs reserved for bad PEB handling: 9

    UBI: max/mean erase counter: 2/0

    Acroviewtech (stock code: 873207) is the first domestic listed company in the burner (programmer) industry, independently owns the R&D, production and service of burner (programmer), automatic burner and automatic online burner At the same time, it has established R&D and production service bases in Shenzhen, Taipei, Suzhou, Yangzhou, and Shanghai. It is the preferred brand of programming solutions for large factories at home and abroad. Acroviewtech has more than 10 years of rich experience in the development, manufacturing and service of programming equipment Experience, world-leading technology, and is committed to providing customers with innovative programming solutions and products. We are working hard to make outstanding contributions to the reliability, security and intellectual property protection of programming equipment. Acroview has always firmly believed that the pursuit of quality and technology will make more and more electronics manufacturers choose Acroview as their trusted partner. New products are continuously being released, please stay tuned.