1. 程式人生 > 其它 >ubi問題總結【轉】

ubi問題總結【轉】

轉自:https://www.cnblogs.com/schips/p/13178836.html

掛載成功有時出現:

UBIFS error (pid 76): ubifs_read_node: bad node type (255 but expected 1)
UBIFS error (pid 76): ubifs_read_node: bad node at LEB 31:20480, LEB mapping status 0
UBIFS error (pid 76): do_readpage: cannot read page 0 of inode 70, error -22

1.在uboot裡,setenv nand_root ubi0:rootfs rw ubi.mtd= (此處對應),2048
2.製作imgae時,mkfs.ubifs -c 這個引數要仔細計算,些引數影響較大,再就是改一下ubinize.cfg這個檔案的相關引數,要經過計算

3.看驅動,以用硬體連線,不要造成flash的只讀情況出現

ubifs_read_node 報錯,還會有類似oops的錯誤

UBIFS: default compressor: LZO
UBIFS: reserved for root:  0 bytes (0 KiB)
UBIFS error (pid 0): ubifs_read_node: bad node type (255 but expected 9)
UBIFS error (pid 0): ubifs_read_node: bad node at LEB 85:60448
UBIFS error (pid 0): ubifs_iget: failed to read inode 1, error -22
Machine check in kernel mode.
Caused by (from msr): regs 0fe7ca88 Unknown values in msr
NIP: 0FFB7C80 XER: 00000000 LR: 0FFB7C5C REGS: 0fe7ca88 TRAP: 0200 DAR: 00000000
MSR: 0000b032 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 11

GPR00: 0004434C 0FE7CB78 0FE7CF50 FFFF7FFF 0FFF8020 00000000 0FFF8020 FFFF7FF7 
GPR08: 00021AE8 DC0FFF80 0FFF83F8 0FFF83F8 22044024 7037FFBF 0FFFB000 00000000 
GPR16: 0FFECF7C 0FFF691C 00000000 00000000 0FEE1310 0FEDFB28 FFFFF000 0FEE0BA0 
GPR24: 00000000 00000003 0FEE129C 00000001 00000001 0FFF9100 0FFFBFA8 0FEE0C88 
Call backtrace: 
0FEE0C88 0FFCABFC 0FFCBEE8 0FFCC050 0FFB6590 0FFBC468 0FFBBB78 
0FFBBD98 0FFBD728 0FFBC468 0FFBBB78 0FFBBD98 0FFBE7D0 0FFA188C 
0FFA05F0 
machine check
Resetting the board.

解決辦法:

關於這個oops的錯誤參考以下連結的修改

http://lists.denx.de/pipermail/u-boot/2011-October/103864.html

On Tue, Oct 4, 2011 at 6:08 PM, larsi <larsi at atlantis.wh2.tu-dresden.de> wrote:
 This patch fixes an issue when ubifs reads a bad superblock. Later it
 tries to free memory, that was not allocated, which freezes u-boot.
 This is fixed by looking for a non null pointer before free.

 Signed-off-by: Lars Poeschel <larsi at wh2.tu-dresden.de>
 Cc: Kyungmin Park <kmpark at infradead.org>
 ---
 The message I got before u-boot freezes:
 UBI: max/mean erase counter: 53/32
 UBIFS: mounted UBI device 0, volume 1, name "rootfs"
 UBIFS: mounted read-only
 UBIFS: file system size:   49140 bytes (50319360 KiB, 0 MiB, 49140 LEBs)
 UBIFS: journal size:       49 bytes (6838272 KiB, 0 MiB, 6678 LEBs)
 UBIFS: media format:       w4/r0 (latest is w4/r0)
 UBIFS: default compressor: LZO
 UBIFS: reserved for root:  0 bytes (0 KiB)
 UBIFS error (pid 0): ubifs_read_node: bad node type (255 but expected 9)
 UBIFS error (pid 0): ubifs_read_node: bad node at LEB 330:13104
 UBIFS error (pid 0): ubifs_iget: failed to read inode 1, error -22
 Error reading superblock on volume 'ubi:rootfs'!

  fs/ubifs/super.c |    6 ++++--
  1 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
 index 63b2164..20fb244 100644
 --- a/fs/ubifs/super.c
 +++ b/fs/ubifs/super.c
 @@ -848,8 +848,10 @@ void ubifs_umount(struct ubifs_info *c)
        ubifs_debugging_exit(c);

        /* Finally free U-Boot's global copy of superblock */
 -       free(ubifs_sb->s_fs_info);
 -       free(ubifs_sb);
 +       if (ubifs_sb != null) {
 +               free(ubifs_sb->s_fs_info);
 +               free(ubifs_sb);
 +       }
Which statement is problem? Basically free() check the null address.
so If ubifs_sb->s_fs_info doesn't have value its skipped. and ubifs_sb
is similar.

Thank you,
Kyungmin Park
  }

但是關於ubifs_read_node: bad node type (255 but expected 9)

這個錯誤一直沒找到精準的解決辦法,開始的時候懷疑mkfs.ubifs的引數問題,各種修改也沒好轉

後來發現kernel的大小(燒寫的時候的大小)不對,

kernel_img=a36800(寫入大小)

ubi write 0x3000000 kernel$kernel_img


Load address: 0x3000000
Loading: #################################################################
         ################################################################
         ####################
done
Bytes transferred = 10792960 (a4b000 hex)(實際大小)

我記得修改過這個引數啊,唉

但不可否認的是改了這兩個地方後,問題就解決了,如果寫入的檔案不完全或被破壞,ubimount時就會出錯

http://www.360doc.com/content/14/1018/14/18578054_417913216.shtml

  • 配置核心,使其支援ubifs檔案系統

    1)Device Drivers --->Memory Technology Device (MTD) support --->UBI - Unsorted block images --->Enable UBI
    2)File systems --->Miscellaneous filesystems --->UBIFS file system support

  • 製作ubifs格式的根檔案系統映象

先說明一下,板子上既有NorFlash,又有NandFlash,其中根檔案系統和應用程式放在NandFlash上,uboot和kernel放在NorFlash上,而根檔案系統所在的mtd裝置為mtd2,分割槽大小為34MiB

  • ./mkfs.ubifs -v -r ./rootfs -o rootfs.img -m 2048 -e 129024 -c 272

  -r:制定檔案內容的位置 -m:頁面大小 -e:邏輯擦除塊大小 -c:最大的邏輯擦除塊數量

1. mkfs.ubifs -m 2048 -e 129024 -c 1984 -o rootfs.ubifs -x none
2.  
3. -m 2048   (Minimum input/output unit size: 2048 bytes)
4. -e 129024 (Default UBI LEB size:           129024 bytes, 126.0 KiB)
5. -c 1984   (Amount of eraseblocks:          1984 (260046848 bytes, 248.0 MiB))
6. -o rootfs.ubifs (output file)
7. -x none   (no compression)
  • ./ubinize -v -o rootfs.ubi -m 2048 -p 128KiB -s 2048 hi.cfg

​ -p:物理擦除塊大小

​ -m:頁面大小

​ -s: 最小的硬體輸入輸出頁面大小,如:k9f1208為256(上下半頁訪問)

配置檔案hi.cfg如下:

[ubifs]
mode=ubi
image=rootfs.img
vol_id=0
vol_size=34MiB
vol_type=dynamic
vol_alignment=1
vol_name=rootfs
vol_flag=autoresize

然後修改uboot的環境變數:

setenv bootargs 'mem=288M console=ttyAMA0,115200  root=ubi0:rootfs rw rootflags=sync rootfstype=ubifs ubi.mtd=2  mtdparts=hi_sfc:5M(boot),1M(picture);hinand:34M(rootfs),8M(config),86M(app)';

儲存環境變數,執行如下命令

setenv ipaddr 192.168.253.132;

setenv serverip 192.168.253.130;

setenv ethaddr 40:61:86:67:33:47;

mw.b 82000000 ff 2200000;

tftp 82000000 rootfs.ubi;

nand erase 0 2200000;

nand write 82000000 0 $(filesize);

sf probe 0;

sf read 0x82000000 0x100000 0x400000;

bootm 0x82000000

說明:

其實從上面的燒寫命令可以看出,ubifs格式的映象中是不包含oob資訊的。

參見:http://www.cnblogs.com/pengdonglin137/p/3399071.html

出現如下錯誤資訊:

UBI: attaching mtd2 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI: max. sequence number: 0
UBI error: vtbl_check: volume table check failed: record 0, error 9
UBI error: ubi_init: cannot attach mtd2
Fixed MDIO Bus: probed

原因:

參考http://wiki.linpert.de/index.php?title=UBIFS#record_0.2C_error_9

http://lists.infradead.org/pipermail/linux-mtd/2009-April/025127.html


But I took a look into the code, and the following is error 9:

if (reserved_pebs > ubi->good_peb_count) {
dbg_err("too large reserved_pebs %d, good PEBs %d",
reserved_pebs, ubi->good_peb_count);
err = 9;
goto bad;
}

This means you created a too large UBI volume in the image,
and your real flash is smaller.

Try to enable UBI debugging, and type dmesg, then you'll see
reserved and real eraseblock numbers.

原因就是:在配置檔案中,volume設為34MiB,太大了,因為整個mtd2分割槽總共才34MiB。

解決辦法:將配置檔案改為:

[ubifs]
mode=ubi
image=rootfs.img
vol_id=0
vol_size=32MiB
vol_type=dynamic
vol_alignment=1
vol_name=rootfs
vol_flag=autoresize

說明:

  • vol_id 表示volume的編號,一個ubi裝置中可以有多個volume。(這種情況下,/dev下會出現 ubi0 和 ubi0_0)
  • vol_size 表示ubi0_0的大小,即volume0的大小
  • vol_type 表示volume0的型別,分為dynamic和static兩種,其中dynamic型別的裝置表示可以讀寫,static型別的裝置表示只讀
  • vol_name 表示volume0的名稱,在掛載ubi分割槽是會使用到,如在bootargs中的root=ubi0:rootfs

然後重新執行:./ubinize -v -o rootfs.ubi -m 2048 -p 128KiB -s 2048 hi.cfg

當再次重啟後,又出現如下錯誤資訊:

UBIFS: parse sync
UBIFS error (pid 1): validate_sb: LEB size mismatch: 129024 in superblock, 126976 real
UBIFS error (pid 1): validate_sb: bad superblock, error 1

原因:

參考:http://www.linux-mtd.infradead.org/faq/ubifs.html#L_lebsz_mismatch

I see this UBIFS error: "validate_sb: LEB size mismatch: 129024 in superblock, 126976 real"

When you create an UBIFS image using themkfs.ubifsutility, you specify LEB size using the-eoption. This is a very important parameter and you should specify it correctly in order to have working UBIFS image. Indeed, LEB size is the major UBIFS storage unit, e.g., UBIFS nodes never cross LEB boundaries, garbage collection is performed on individual LEBs, etc. See this section for more information.

The error message means that LEB size information which is stored in the UBIFS superblock does not match the real LEB size, which UBIFS takes from UBI. The superblock was created by themkfs.ubifsutility, therefore you failed to pass the correct LEB size to the utility. Fix this by passing correct LEB size via the -e option.

原因是:邏輯塊的大小與實際的大小不符

解決辦法:

將-e選項的值由129024改成126976

重新執行:

 ./mkfs.ubifs -v -r ./rootfs -o rootfs.img -m 2048 -e 126976 -c 272

 ./ubinize -v -o rootfs.ubi -m 2048 -p 128KiB -s 2048 hi.cfg

重新燒寫並重啟。

還有一個需要注意的問題是,如果將-s選項的值搞錯,如將2048寫成了512,那麼會有如下錯誤資訊

UBI error: validate_ec_hdr: bad VID header offset 512, expected 2048
UBI error: validate_ec_hdr: bad EC header
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
UBI error: ubi_init: cannot attach mtd2
Fixed MDIO Bus: probed

從錯誤提示中就可以看到解決方法:將-s選項的值改為2048即可。

參考:http://www.cnblogs.com/pengdonglin137/p/3404685.html

UBI headers

UBI stores 2 small 64-byte headers at the beginning of each non-bad physical eraseblock:

  • erase counter header (or EC header) which contains the erase counter of the physical eraseblock (PEB) plus some other not so important information;
  • volume identifier header (or VID header) which stores volume ID and logical eraseblock (LEB) number this PEB belongs to (plus some other not so important information).

This is why logical eraseblocks are smaller than physical eraseblock - the headers take some flash space.

UBI headers position

The EC header always resides at offset 0 and takes 64 bytes, the VID header resides at the next available min. I/O unit or sub-page, and also takes 64 bytes. For example:

  • in case of NOR flash which has 1 byte min. I/O unit, the VID header resides at offset 64;
  • in case of NAND flash which does not have sub-pages, the VID header resides at the second NAND page;
  • in case of NAND flash which has sub-pages, the VID header resides at the second sub-page.

UBI utilizes sub-pages to lessen flash space overhead. The overhead is less if NAND flash supports sub-pages (see here). Indeed, let's consider a NAND flash with 128KiB eraseblocks and 2048-byte pages. If it does not have sub-pages, UBI puts the the VID header at physical offset 2048, so LEB size becomes 124KiB (128KiB minus one NAND page which stores the EC header and minus another NAND page which stores the VID header. In opposite, if the NAND flash does have sub-pages, UBI puts the VID header at physical offset 512 (the second sub-page), so LEB size becomes 126KiB (128KiB minus one NAND page which is used for storing both UBI headers). See this section for more information about where the UBI headers are stored.

也就是說,對於上面的例子,如果有subpage(可以到/sys/class/mtd/其中的一個目錄下使用cat命令去檢視某個mtd裝置的subpagesize引數),如果是512B,這有如下引數搭配(對於塊大小是128KiB,頁大小是2KB的NandFlash來說):

 ./mkfs.ubifs -v -r ./rootfs -o rootfs.img -m 2048 -e 129024 -c 272 
 ./ubinize -v -o rootfs.ubi -m 2048 -p 128KiB -s 512 hi.cfg

其中 -e表示的是邏輯塊的大小,因為subpagesize大小是512(也就是-s選項的值),第一頁的前512存放EC(實際用了前64B),接下來的512B(前64B)存放UBI headers,邏輯塊的大小就是128KiB-2KiB=126KiB,轉化成十進位制就是129024。

假如沒有subpagesize,那麼有如下搭配:

./mkfs.ubifs -v -r ./rootfs -o rootfs.img -m 2048 -e 126976 -c 272 

./ubinize -v -o rootfs.ubi -m 2048 -p 128KiB -s 2048 hi.cfg

其中,邏輯塊的大小:128KiB-2KiB-2KiB=124KiB,轉換成10進位制就是126976,-s後面的值為頁大小,即2048B。

https://blog.csdn.net/davion_zhang/article/details/47400553

http://www.360doc.com/content/14/1018/14/18578054_417913216.shtml

如果說我的文章對你有用,只不過是我站在巨人的肩膀上再繼續努力罷了。
若在頁首無特別宣告,本篇文章由Schips經過整理後釋出。
部落格地址:https://www.cnblogs.com/schips/