CN116361817A - 一种Linux下ubi文件***的保护方法 - Google Patents
一种Linux下ubi文件***的保护方法 Download PDFInfo
- Publication number
- CN116361817A CN116361817A CN202310643945.4A CN202310643945A CN116361817A CN 116361817 A CN116361817 A CN 116361817A CN 202310643945 A CN202310643945 A CN 202310643945A CN 116361817 A CN116361817 A CN 116361817A
- Authority
- CN
- China
- Prior art keywords
- partition
- static
- ubi
- dynamic
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 238000005192 partition Methods 0.000 claims abstract description 358
- 230000003068 static effect Effects 0.000 claims abstract description 152
- 238000003860 storage Methods 0.000 claims abstract description 31
- 238000011084 recovery Methods 0.000 claims abstract description 24
- 238000001514 detection method Methods 0.000 claims abstract description 13
- 238000002360 preparation method Methods 0.000 claims description 4
- 238000004519 manufacturing process Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 101100036896 Schizosaccharomyces pombe (strain 972 / ATCC 24843) uep1 gene Proteins 0.000 claims description 2
- 230000006870 function Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 6
- 238000000638 solvent extraction Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 3
- 208000033999 Device damage Diseases 0.000 description 1
- 101100307851 Drosophila melanogaster RpS27A gene Proteins 0.000 description 1
- 101100208690 Drosophila melanogaster Ubi-p63E gene Proteins 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 229910002056 binary alloy Inorganic materials 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44594—Unloading
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供一种Linux下ubi文件***的保护方法，包括以下步骤：S1、在内核设备树中对flash进行分区处理，将其分为多个块设备，得到多个flash节点；S2、将flash节点添加到8个分区中；S3、将3个分区烧写静态卷，得到两个静态应用分区和一个静态参数分区，2个分区烧写动态卷，得到一个动态参数分区和一个动态存储分区；S4、挂载动态参数分区，对其进行分区状态检测，判断是否挂载成功，若是，则进行S5，若否，则进行动态参数分区恢复，完成后进行S5；S5、遍历动态参数分区文件，读取动态参数分区下的START_P标志位，基于START_P标志位挂载相应静态应用分区，启动静态应用分区中的应用程序。
Description
技术领域
本发明涉及一种ubi文件***，尤其涉及一种Linux下ubi文件***的保护方法。
背景技术
UBI全称Unsorted Block Images,是一种原始flash设备的卷管理***。这个***能在一个物理的flash设备上管理多个卷并且能在整个flash芯片上实现损耗均衡。在嵌入式领域flash的地位类似于PC上的硬盘。而ubi文件***类似于PC上常用的ext4、ntfs等文件***格式。它屏蔽了底层硬件，为用户提供了统一的接口，使用户可以很方便的进行文件操作。同时也具备UBI管理的功能，可以将数据从损耗严重的物理块转移到损耗较少的擦除块，达到损耗均衡的目的，延长了flash的使用寿命。
以嵌入式设备中大量使用的nandflash为例进行说明，其它flash问题类似。在实际使用中，除了寿命问题，nandflash还有位翻转(bit-filps)和坏块(Bad Block)。
NAND闪存容易受到读写操作中发生的位翻转错误的影响。位翻转由ECC校验和纠正，但它们可能会随着时间的推移累积并导致数据丢失。UBI通过将数据从具有位翻转的物理擦除块移动到其他物理擦除块来处理这个问题。这个过程称为scrub。scrub工作在后台透明地完成，并且对上层隐藏。UBI会处理坏的擦除块，无需上层软件参与。UBI有一个保留的物理擦除块池，当一个物理擦除块变坏时，它会透明地用一个好的物理擦除块替换它。UBI 将数据从新发现的坏物理擦除块移动到好的物理擦除块。 结果是 UBI 卷的用户不会注意到I/O错误，因为UBI会透明地处理它们。
然而ubi的校正功能有限，在实际使用过程中，由于flash芯片本身的质量问题、***异常甚至是突然断电都会出现无法恢复的错误。如果***中运行中出现ECC error则会导致文件***变为只读，甚至是驱动崩溃导致内核panic。如果开机时出现问题，则直接导致文件***挂载不上，***启动错误。这些异常很难从硬件、驱动或者文件***层面永远解决。
发明内容
针对上述问题，本发明提供一种Linux下ubi文件***的保护方法；基于Linux块设备驱动技术和ubi卷技术实现静态分区和动态分区，按照嵌入式设备的运行逻辑，将分区分为应用分区、参数分区、存储分区。根据重要程度和写操作频率制定了符合用户需求的保护和恢复策略。应用分区使用两个静态分区完成升级、版本回退、备份启动的功能。参数分区使用“一动一静”的分区方案，使用动态分区去同步静态分区，使用静态分区去恢复动态分区。存储分区配合服务器完成自动化检测和分区恢复的功能。
为实现上述目的，本发明公开了一种Linux下ubi文件***的保护方法，包括以下步骤：
S1、在内核设备树中对flash进行分区处理，将flash分为多个块设备，由此得到多个flash设备节点；
S2、将flash设备节点添加到partition@0-partition@2A000000这8个分区；
S3、将其中3个分区烧写ubi静态卷，从而得到两个静态应用分区和一个静态参数分区，其中2个分区烧写ubi动态卷，从而得到一个动态参数分区和一个动态存储分区；
S4、挂载动态参数分区，对其进行分区状态检测，判断是否挂载成功，若是，则进行S5，若否，则进行动态参数分区恢复，完成后进行S5；
S5、遍历动态参数分区文件，读取动态参数分区下的START_P标志位，基于START_P标志位挂载相应静态应用分区，启动静态应用分区中的应用程序。
进一步的，ubi卷的制作方法为：
1）mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 1900–F
2）ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinize.cfg
其中source_dir是做成ubi的文件目录，target.ubi是最终生成的ubi卷文件***镜像，ubinize.cfg是制作ubi卷文件***所需的配置文件，在配置文件中通过vol_type参数指定要创建分区的类型，若vol_type=dynamic，则为动态分区，若vol_type=static，则为静态分区。
进一步的，步骤S3中所烧写的动态参数分区用于***运行挂载，静态参数分区作为动态参数分区的备份，用于动态参数分区的恢复，并且静态参数分区通过如下方式进行更新，以保证静态参数分区始终为最新状态：
对挂载的动态参数分区进行检测，当发现挂载的动态参数分区有修改时通过如下实现对修改后的动态参数分区进行打包，生成静态参数分区镜像并烧写至静态参数分区中：
mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 370–F
ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinizes.cfg
ubiformat /dev/mtd7 -f target.ubi -y
rm target.ubi target.ubifs
其中source_dir是发生写操作以后的动态参数分区文件目录，target.ubi是基于最新的文件制作生成的静态参数分区镜像，ubinizes.cfg是制作静态参数分区镜像需要的配置文件；
最后使用ubiformat将静态参数分区镜像target.ubi烧写到静态参数分区/dev/mtd7中。
进一步的，所述S4中的动态参数分区恢复方法为：
1）ubiattach解除已损坏ubi设备的挂载，执行flash_eraseall对动态参数分区进行硬件擦除，ubiformat重新格式化动态参数分区，ubiattach重新挂载文件***，mount重新挂载到arg目录；
2）挂载静态参数分区，将静态参数分区中的文件重新拷贝到动态参数分区目录下，完成后卸载静态参数分区。
进一步的，还通过定时任务检测动态存储分区，在动态存储分区有损坏时，通过如下方法进行动态存储分区的恢复：
ubiformat /dev/mtd8 -y
ubiattach /dev/ubi_ctrl -m 8 -d 2
ubimkvol /dev/ubi2 -N storfs -s 300MiB
mount -t ubifs -o sync /dev/ubi2_0 stor
其中mtd8是动态存储分区对应mtd编号，stor是动态存储分区在***中的挂载目录。
进一步的，在通过步骤S5完成静态应用分区挂载后，若监测到进行了应用升级，则在升级进程中判断START_P的值，并在升级后修改START_P标志位，基于修改后的START_P标志位重新挂载升级后的静态应用分区，并对重新挂载后的静态应用分区进行分区状态检测，若失败，则挂载另一块静态应用分区并将start_f标志位置1，完成静态应用分区挂载；
同时，通过START_UPDATE标志位判断重启之前是否进行了应用升级：
若该START_UPDATE标志位为0，则说明没有进行应用升级，直接启动静态应用分区中的应用程序；
若该标志位为1，且start_f==1，则说明有升级任务，但是升级的静态应用分区已损坏，所以挂载了另一个静态应用分区，此时也直接启动静态应用分区中的应用程序；若start_f==0，则升级后的静态应用分区挂载成功，进行版本号的判断，若挂载版本号==升级版本号，则升级成功且挂载成功，此时也直接启动静态应用分区中的应用程序，若挂载版本号不等于升级版本号则说明升级版本有误，则说明升级错误，此时进行版本回退，在回退后再启动静态应用分区中的应用程序。
本发明的一种Linux下ubi文件***的保护方法的有益效果为：基于Linux块设备驱动技术和ubi卷技术实现静态分区和动态分区，按照嵌入式设备的运行逻辑，将分区分为应用分区、参数分区、存储分区。根据重要程度和写操作频率制定了符合用户需求的保护和恢复策略。应用分区使用两个静态分区完成升级、版本回退、备份启动的功能。参数分区使用“一动一静”的分区方案，使用动态分区去同步静态分区，使用静态分区去恢复动态分区。存储分区配合服务器完成自动化检测和分区恢复的功能
附图说明
图1是本发明实施例的Nandflash分区示意图。
图2是本发明实施例的整体流程示意图。
图3是本发明实施例的升级和开机检测流程示意图。
具体实施方式
下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。
本申请公开了一种Linux下ubi文件***的保护方法，包括以下步骤：
S1、在内核设备树中对flash进行分区处理，将flash分为多个块设备，由此得到多个flash设备节点；
S2、将flash设备节点添加到partition@0-partition@2A000000这8个分区；
S3、将其中3个分区烧写ubi静态卷，从而得到两个静态应用分区和一个静态参数分区，其中2个分区烧写ubi动态卷，从而得到一个动态参数分区和一个动态存储分区；
S4、挂载动态参数分区，对其进行分区状态检测，判断是否挂载成功，若是，则进行S5，若否，则进行动态参数分区恢复，完成后进行S5；
S5、遍历动态参数分区文件，读取动态参数分区下的START_P标志位，基于START_P标志位挂载相应静态应用分区，启动静态应用分区中的应用程序。
其中，ubi卷的制作方法为：
1）mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 1900–F
2）ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinize.cfg
其中source_dir是做成ubi的文件目录，target.ubi是最终生成的ubi卷文件***镜像，ubinize.cfg是制作ubi卷文件***所需的配置文件，在配置文件中通过vol_type参数指定要创建分区的类型，若vol_type=dynamic，则为动态分区，若vol_type=static，则为静态分区。
为进一步优化上述技术方案，步骤S3中所烧写的动态参数分区用于***运行挂载，静态参数分区作为动态参数分区的备份，用于动态参数分区的恢复，并且静态参数分区通过如下方式进行更新，以保证静态参数分区始终为最新状态：
对挂载的动态参数分区进行检测，当发现挂载的动态参数分区有修改时通过如下实现对修改后的动态参数分区进行打包，生成静态参数分区镜像并烧写至静态参数分区中：
mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 370–F
ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinizes.cfg
ubiformat /dev/mtd7 -f target.ubi-y
rm target.ubi target.ubifs
其中source_dir是发生写操作以后的动态参数分区文件目录，target.ubi是基于最新的文件制作生成的静态参数分区镜像，ubinizes.cfg是制作静态参数分区镜像需要的配置文件；
最后使用ubiformat将静态参数分区镜像target.ubi烧写到静态参数分区/dev/mtd7中。
为进一步优化上述技术方案，S4中的动态参数分区恢复方法为：
1）ubiattach解除已损坏ubi设备的挂载，执行flash_eraseall对动态参数分区进行硬件擦除，ubiformat重新格式化动态参数分区，ubiattach重新挂载文件***，mount重新挂载到arg目录
2）挂载静态参数分区，将静态参数分区中的文件重新拷贝到动态参数分区目录下，完成后卸载静态参数分区。
为进一步优化上述技术方案，还通过定时任务检测动态存储分区，在动态存储分区有损坏时，通过如下方法进行动态存储分区的恢复：
ubiformat/dev/mtd8-y
ubiattach/dev/ubi_ctrl-m 8-d 2
ubimkvol/dev/ubi2-N storfs-s 300MiB
mount-t ubifs-o sync/dev/ubi2_0stor
其中mtd8是动态存储分区对应mtd编号，stor是动态存储分区在***中的挂载目录。
为进一步优化上述技术方案，在通过步骤S5完成静态应用分区挂载后，若监测到进行了应用升级，则在升级进程中判断START_P的值，并在升级后修改START_P标志位，基于修改后的START_P标志位重新挂载升级后的静态应用分区，并对重新挂载后的静态应用分区进行分区状态检测，若失败，则挂载另一块静态应用分区并将start_f标志位置1，完成静态应用分区挂载；
同时，通过START_UPDATE标志位判断重启之前是否进行了应用升级：
若该START_UPDATE标志位为0，则说明没有进行应用升级，直接启动静态应用分区中的应用程序；
若该标志位为1，且start_f==1，则说明有升级任务，但是升级的静态应用分区已损坏，所以挂载了另一个静态应用分区，此时也直接启动静态应用分区中的应用程序；若start_f==0，则升级后的静态应用分区挂载成功，进行版本号的判断，若挂载版本号==升级版本号，则升级成功且挂载成功，此时也直接启动静态应用分区中的应用程序，若挂载版本号不等于升级版本号则说明升级版本有误，则说明升级错误，此时进行版本回退，在回退后再启动静态应用分区中的应用程序。
本申请的实施例于NXP的LS1021A芯片，采用Cortex-A7架构，Linux 4.19内核。使用1G的nandflash作为ubi文件***管理设备。
1、nandflash分区划分
传统的nandflash使用方法是作为一个块设备挂载到***中。这块flash设备主要存储应用程序、程序参数、日志等。这些内容有些是不需要写的，有些是需要频繁写的。一旦出现写错误，就会相互影响，导致整个分区挂载不上。分区的目的是按照读写的需要，划分成不同的分区。这样就不会相互影响，把风险降到最低。运行在工控现场的嵌入式设备相比普通计算机有以下区别：工控设备更注重稳定。这种情况一般可以分为应用分区、参数分区和存储区。应用区用于存放用户的应用程序，通常不需要频繁修改，***启动时自动将应用程序读取到内存运行，后续运行不会去修改应用程序的二进制（除非是应用升级）。参数分区是存放应用运行一些必备参数，它可以是应用程序启动时直接读取的默认配置，也可以后期通过网络远程修改以满足用户的个性化需求。所以这块分区需要具有读写权限。但是即使是用户配置也不会频繁更改。最后存储分区是用于存放***需要保存的运行日志等临时文件。这个分区相比于参数分区写操作会更加频繁。但是幸运的是这块分区通常不会影响***的正常启动和运行。最严重的情况是运行时出现存储分区变为只读的情况。所以这三个分区写操作的频率为存储分区>参数分区>应用分区，而重要程度为存储分区<参数分区<应用分区。正是基于这种逻辑差，我们制定了这种分区保护方案。同时，操作***镜像uboot、dtb（设备树）、kernel（内核）、ramdisk（内存文件***）也不需要写权限，我们将他们统一作为静态区来处理。
动态分区和静态分区的实现如下：首先需要在内核层对nandflash进行分区处理，将一块flash分为多个MTD块设备。MTD是内核的flash设备硬件抽象层，用于屏蔽不同Flash的操作差异，向上提供统一的操作接口 。UBI是基于MTD，在MTD上实现nand特性的管理逻辑，向上屏蔽nand的特性。具体实现是在内核设备树中进行分割，将设备树中nandflash设备节点添加partition@0-partition@2A000000 8个分区，具体起始地址和大小按照图1中修改。
分区完成以后需要制作对各个分区的镜像，然后烧写到对应的分区中去。其中分区中烧写ubi静态卷的称为静态分区，烧写ubi动态卷的称为动态分区。ubi卷的制作方法如下：
1）mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 1900–F
2）ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinize.cfg
其中source_dir是需要做成ubi的文件目录，target.ubi是最终生成的ubi卷文件***镜像。ubinize.cfg是制作ubi卷文件***所需的配置文件。在配置文件中通过vol_type参数指定要创建分区的类型。如果vol_type=dynamic，则为动态分区，如果vol_type=static，则为静态分区。
如图1所示，将原来的nandflash分区，分为了两个静态应用分区、动态参数分区和静态参数分区、动态存储分区。其中两块静态应用分区互为备份。参数分区分为静态区和动态区，动态区用于***运行挂载，静态区作为动态区的备份，用于动态区恢复使用。参数分区的特点是不会频繁写操作，一般在设备启动以后，用户会进行参数修改以满足自己的个性化需求，或者在设备功能变化时进行用户参数重新设置以满足需求。但是这种写操作的频率有限，我们通过对挂载的动态参数分区进行检测，如果发现挂载分区有修改则直接将修改以后的分区重新打包，生成静态分区镜像并烧写到静态参数分区中去。这样保证静态参数分区始终是最新状态。具体实现如下：
mkfs.ubifs-r source_dir-o target.ubifs-m 2048-e 126976-c 370–F
ubinize -o target.ubi-m 2048-p 128KiB-s 2048 ubinizes.cfg
ubiformat/dev/mtd7 -f target.ubi-y
rm target.ubi target.ubifs
其中source_dir是发生写操作以后的动态参数分区文件目录，target.ubi 是基于最新的文件制作生成的静态分区镜像，ubinizes.cfg是制作静态镜像需要的配置文件。最后使用ubiformat将静态镜像target.ubi烧写到静态参数分区/dev/mtd7中。
动态存储分区对于***的重要程度相对较小。也就是说即使损坏也不会影响***启动，且不会在短时间内影响***运行。针对动态存储分区我们使用crond设置定时任务去循环检测分区状态。定时任务不需要太频繁，所以不会对cpu产生压力。如果定时检测到分区损坏，首先对现有文件进行打包上传服务器的特定存储区如日志文件管理区，然后执行分区恢复操作。动态存储分区恢复流程如下：
ubiformat/dev/mtd8-y
ubiattach/dev/ubi_ctrl-m 8-d 2
ubimkvol/dev/ubi2-N storfs-s 300MiB
mount-t ubifs-o sync/dev/ubi2_0stor
其中mtd8是动态存储分区对应mtd编号，stor是动态存储分区在***中的挂载目录。
2、分区管理
如图3所示，设备开机时首先挂载动态参数分区，因为在动态参数分区中存放了START_P指针（用于指向挂载哪个静态应用分区）、START_UPDATE(用于指示设备是否发生了升级服务)、start_f(用于表示本次启动中是否发生应用分区挂载错误)等参数。这些参数用于***启动的逻辑判断。挂载动态参数分区时会进行分区状态检测，挂载成功以后遍历参数分区文件。只有所有状态检测都通过时才进行后续的静态应用分区挂载操作。如果其中有一步判断分区或者文件损坏，则首先进行动态参数分区恢复操作，再进行静态应用分区挂载。动态参数分区恢复可以分为以下步骤：
1）ubiattach解除已损坏ubi设备的挂载，执行flash_eraseall对动态参数分区进行硬件擦除。ubiformat重新格式化动态参数分区，ubiattach重新挂载文件***，mount重新挂载到arg目录。
具体的命令实现如下：
ubidetach -d 1
flash_eraseall /dev/mtd6
ubiformat /dev/mtd6 -y
ubiattach /dev/ubi_ctrl -m 6 -d 1
ubimkvol /dev/ubi1 -N paramfs -s 120MiB
mount -t ubifs -o sync /dev/ubi1_0 arg
其中arg是用于在***运行时挂载动态参数分区的目录
2）接下来挂载静态参数分区，将静态参数分区中的文件重新拷贝到动态参数分区目录下。最后卸载静态参数分区。
具体的命令实现如下：
mkdir arg_bak
ubiattach /dev/ubi_ctrl -m 7 -d 3
mount -t ubifs -o ro /dev/ubi3_0 arg_bak
cp -rf arg_bak/* arg
umount arg_bak
ubidetach -d 3
rm -rf arg_bak
其中arg_bak是用于动态参数分区恢复时，临时挂载静态参数分区的目录。一旦恢复过程完成，需要即刻删除该目录。
静态参数分区只在恢复动态参数分区时才临时挂载使用，完成恢复以后随即卸载。***在正常运行时是不需要挂载的。动态存储分区是在挂载完参数分区和应用分区以后挂载的。也就是参数和应用分区经过检测、恢复、升级流程以后，启动静态应用分区中的应用程序之前的时刻挂载。
动态参数分区挂载以后首先读取分区下的START_P标志位，根据标志位挂载相应静态应用分区。START_P ==4表示***启动需要挂载的是mtd4，START_P ==5挂载的是mtd5。
如果设备在运行时进行了应用升级，那么升级进程会判断START_P的值，如果为4，则表明设备目前挂载的是mtd4，则需要升级的就是mtd5分区。升级成功以后，修改START_P为5，然后设备重启。设备重启以后挂载mtd5，也就是最新升级的应用分区。此部分逻辑对应图3右上角：升级流程开始-根据START_P升级对应应用分区-判断升级成功与否，成功后修改START_P指向升级后的分区-根据START_P挂载对应应用分区。
静态应用分区挂载时首先进行分区状态检测，检测原理与动态参数分区的流程相似。不同的是如果检测失败，则直接进行版本回退，挂载另一块静态应用分区，并将start_f标志位置1。完成静态应用分区挂载以后通过START_UPDATE标志位判断重启之前设备是否进行了应用升级。如果该标志位为0，则说明设备没有升级任务，直接启动静态应用分区中的应用程序。如果该标志位为1，且start_f==1，则说明虽然有升级任务，但是升级分区已然损坏，所以被迫挂载上个版本的静态应用分区，并直接启动静态应用分区中的应用程序。如果start_f==0，则说明升级分区已经挂载成功，这时我们还需要再进行版本号的判断，如果挂载版本号==升级版本号，说明升级成功且挂载成功，此时也直接启动静态应用分区中的应用程序。如果挂载版本号不等于升级版本号则说明升级版本有误，依然需要进行版本回退，在回退后再启动静态应用分区中的应用程序。
本申请基于Linux块设备驱动技术和ubi卷技术实现静态分区和动态分区，按照嵌入式设备的运行逻辑，将分区分为应用分区、参数分区、存储分区。根据重要程度和写操作频率制定了符合用户需求的保护和恢复策略。应用分区使用两个静态分区完成升级、版本回退、备份启动的功能。参数分区使用“一动一静”的分区方案，使用动态分区去同步静态分区，使用静态分区去恢复动态分区。存储分区配合服务器完成自动化检测和分区恢复的功能。
应用了本发明的设备在长时间的运行中未出现过开机失败和运行中因块设备损坏导致的崩溃问题，并尽可能的保存了运行数据的完整性。其中应用分区未出现过损坏的情况，参数分区发生了相对较多的恢复流程，但最终都恢复成功，并未影响到设备运行。存储分区发生恢复流程的情况最多，也导致了少量日志文件的丢失，但影响有限，未影响到设备的安全运行。
显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
Claims (6)
1.一种Linux下ubi文件***的保护方法，其特征在于，包括以下步骤：
S1、在内核设备树中对flash进行分区处理，将flash分为多个块设备，由此得到多个flash设备节点；
S2、将flash设备节点添加到partition@0-partition@2A000000这8个分区；
S3、将其中3个分区烧写ubi静态卷，从而得到两个静态应用分区和一个静态参数分区，其中2个分区烧写ubi动态卷，从而得到一个动态参数分区和一个动态存储分区；
S4、挂载动态参数分区，对其进行分区状态检测，判断是否挂载成功，若是，则进行S5，若否，则进行动态参数分区恢复，完成后进行S5；
S5、遍历动态参数分区文件，读取动态参数分区下的START_P标志位，基于START_P标志位挂载相应静态应用分区，启动静态应用分区中的应用程序。
2.基于权利要求1所述的一种Linux下ubi文件***的保护方法，其特征在于，ubi卷的制作方法为：
1）mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 1900–F
2）ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinize.cfg
其中source_dir是做成ubi的文件目录，target.ubi是最终生成的ubi卷文件***镜像，ubinize.cfg是制作ubi卷文件***所需的配置文件，在配置文件中通过vol_type参数指定要创建分区的类型，若vol_type=dynamic，则为动态分区，若vol_type=static，则为静态分区。
3.基于权利要求1所述的一种Linux下ubi文件***的保护方法，其特征在于，步骤S3中所烧写的动态参数分区用于***运行挂载，静态参数分区作为动态参数分区的备份，用于动态参数分区的恢复，并且静态参数分区通过如下方式进行更新，以保证静态参数分区始终为最新状态：
对挂载的动态参数分区进行检测，当发现挂载的动态参数分区有修改时通过如下实现对修改后的动态参数分区进行打包，生成静态参数分区镜像并烧写至静态参数分区中：
mkfs.ubifs -r source_dir -o target.ubifs -m 2048 -e 126976 -c 370–F
ubinize -o target.ubi -m 2048 -p 128KiB -s 2048 ubinizes.cfg
ubiformat /dev/mtd7 -f target.ubi -y
rm target.ubi target.ubifs
其中source_dir是发生写操作以后的动态参数分区文件目录，target.ubi是基于最新的文件制作生成的静态参数分区镜像，ubinizes.cfg是制作静态参数分区镜像需要的配置文件；
最后使用ubiformat将静态参数分区镜像target.ubi烧写到静态参数分区/dev/mtd7中。
4.基于权利要求1所述的一种Linux下ubi文件***的保护方法，其特征在于，所述S4中的动态参数分区恢复方法为：
1）ubiattach解除已损坏ubi设备的挂载，执行flash_eraseall对动态参数分区进行硬件擦除，ubiformat重新格式化动态参数分区，ubiattach重新挂载文件***，mount重新挂载到arg目录；
2）挂载静态参数分区，将静态参数分区中的文件重新拷贝到动态参数分区目录下，完成后卸载静态参数分区。
5.基于权利要求1所述的一种Linux下ubi文件***的保护方法，其特征在于，还通过定时任务检测动态存储分区，在动态存储分区有损坏时，通过如下方法进行动态存储分区的恢复：
ubiformat /dev/mtd8 -y
ubiattach /dev/ubi_ctrl -m 8 -d 2
ubimkvol /dev/ubi2 -N storfs -s 300MiB
mount -t ubifs -o sync /dev/ubi2_0 stor
其中mtd8是动态存储分区对应mtd编号，stor是动态存储分区在***中的挂载目录。
6.基于权利要求1所述的一种Linux下ubi文件***的保护方法，其特征在于，在通过步骤S5完成静态应用分区挂载后，若监测到进行了应用升级，则在升级进程中判断START_P的值，并在升级后修改START_P标志位，基于修改后的START_P标志位重新挂载升级后的静态应用分区，并对重新挂载后的静态应用分区进行分区状态检测，若失败，则挂载另一块静态应用分区并将start_f标志位置1，完成静态应用分区挂载；
同时，通过START_UPDATE标志位判断重启之前是否进行了应用升级：
若该START_UPDATE标志位为0，则说明没有进行应用升级，直接启动静态应用分区中的应用程序；
若该标志位为1，且start_f==1，则说明有升级任务，但是升级的静态应用分区已损坏，所以挂载了另一个静态应用分区，此时也直接启动静态应用分区中的应用程序；若start_f==0，则升级后的静态应用分区挂载成功，进行版本号的判断，若挂载版本号==升级版本号，则升级成功且挂载成功，此时也直接启动静态应用分区中的应用程序，若挂载版本号不等于升级版本号则说明升级版本有误，则说明升级错误，此时进行版本回退，在回退后再启动静态应用分区中的应用程序。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310643945.4A CN116361817B (zh) | 2023-06-02 | 2023-06-02 | 一种Linux下ubi文件***的保护方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310643945.4A CN116361817B (zh) | 2023-06-02 | 2023-06-02 | 一种Linux下ubi文件***的保护方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116361817A true CN116361817A (zh) | 2023-06-30 |
| CN116361817B CN116361817B (zh) | 2023-08-22 |
Family
ID=86910959
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310643945.4A Active CN116361817B (zh) | 2023-06-02 | 2023-06-02 | 一种Linux下ubi文件***的保护方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116361817B (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117707629A (zh) * | 2023-08-09 | 2024-03-15 | 荣耀终端有限公司 | ***启动方法、可读存储介质和电子设备 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102298555A (zh) * | 2011-08-22 | 2011-12-28 | 宜兴市华星特种陶瓷科技有限公司 | 基于nand技术的模块化闪存管理*** |
| CN103473067A (zh) * | 2013-09-23 | 2013-12-25 | 福建三元达软件有限公司 | 嵌入式Linux分区与数据还原方法、***及***开发方法 |
| US20140359205A1 (en) * | 2012-01-31 | 2014-12-04 | Kyocera Document Solutions Inc. | Mounting method in an electronic apparatus |
| WO2015070521A1 (zh) * | 2013-11-12 | 2015-05-21 | 上海斐讯数据通信技术有限公司 | 将ubi格式的***文件制作成工厂烧录映像文件方法 |
| CN107943414A (zh) * | 2017-10-16 | 2018-04-20 | 积成电子股份有限公司 | 嵌入式Linux的文件***分区及数据读写方法 |
| CN112579179A (zh) * | 2019-09-30 | 2021-03-30 | 合肥杰发科技有限公司 | 一种嵌入式***的分区挂载方法 |
| CN112783537A (zh) * | 2020-12-31 | 2021-05-11 | 浙江万胜智能科技股份有限公司 | 基于MTD存储设备的嵌入式linux操作***升级方法及*** |
-
2023
- 2023-06-02 CN CN202310643945.4A patent/CN116361817B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102298555A (zh) * | 2011-08-22 | 2011-12-28 | 宜兴市华星特种陶瓷科技有限公司 | 基于nand技术的模块化闪存管理*** |
| US20140359205A1 (en) * | 2012-01-31 | 2014-12-04 | Kyocera Document Solutions Inc. | Mounting method in an electronic apparatus |
| CN103473067A (zh) * | 2013-09-23 | 2013-12-25 | 福建三元达软件有限公司 | 嵌入式Linux分区与数据还原方法、***及***开发方法 |
| WO2015070521A1 (zh) * | 2013-11-12 | 2015-05-21 | 上海斐讯数据通信技术有限公司 | 将ubi格式的***文件制作成工厂烧录映像文件方法 |
| CN107943414A (zh) * | 2017-10-16 | 2018-04-20 | 积成电子股份有限公司 | 嵌入式Linux的文件***分区及数据读写方法 |
| CN112579179A (zh) * | 2019-09-30 | 2021-03-30 | 合肥杰发科技有限公司 | 一种嵌入式***的分区挂载方法 |
| CN112783537A (zh) * | 2020-12-31 | 2021-05-11 | 浙江万胜智能科技股份有限公司 | 基于MTD存储设备的嵌入式linux操作***升级方法及*** |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117707629A (zh) * | 2023-08-09 | 2024-03-15 | 荣耀终端有限公司 | ***启动方法、可读存储介质和电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116361817B (zh) | 2023-08-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8417992B2 (en) | Method, system and article of manufacture for system recovery | |
| US7185071B2 (en) | Self-healing version and configuration model for an application server | |
| US7761732B2 (en) | Data protection in storage systems | |
| US7711989B2 (en) | Storage system with automatic redundant code component failure detection, notification, and repair | |
| US6591376B1 (en) | Method and system for failsafe recovery and upgrade of an embedded operating system | |
| US6205558B1 (en) | Recovery of file systems after modification failure | |
| KR100515890B1 (ko) | 효율적인 데이터베이스 복구방법 | |
| CN111562934B (zh) | 一种基于热补丁的软件***升级方法、终端及存储介质 | |
| CN109086078B (zh) | 安卓***升级方法、装置、服务器及移动终端 | |
| US20130055019A1 (en) | Pilot Process Method for System Boot and Associated Apparatus | |
| US7487385B2 (en) | Apparatus and method for recovering destroyed data volumes | |
| CN116361817B (zh) | 一种Linux下ubi文件***的保护方法 | |
| RU2248627C2 (ru) | Способ и устройство для изменения содержимого запоминающих устройств блоков управления | |
| CN111552592A (zh) | 一种双备份启动方法及*** | |
| CN106033362A (zh) | 一种闪存分区的处理方法和装置 | |
| CN111258666A (zh) | 计算机文件的读取方法、装置、计算机***及存储介质 | |
| CN113157303A (zh) | 升级方法、嵌入式***、终端及计算机存储介质 | |
| CN112269679B (zh) | 一种云平台的数据库持久化方法、***、设备及存储介质 | |
| CN114063901A (zh) | Plp备份失败之后的ssd支持只读模式 | |
| CN114489813A (zh) | 配置操作***制式的方法、设备及存储介质 | |
| KR100853941B1 (ko) | 멀티미디어 저장장치와 데이터 복구방법 | |
| WO2023103755A1 (zh) | 终端的启动方法、电子设备和计算机可读存储介质 | |
| CN115617488A (zh) | 操作***迁移方法、装置、计算设备及存储介质 | |
| CN112579179A (zh) | 一种嵌入式***的分区挂载方法 | |
| KR101850272B1 (ko) | 빠른 부팅을 위한 부트 이미지를 업데이트하는 방법 및 이를 수행하는 화상형성장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |