• FL2440 ubifs文件系统烧录遇到的问题——内核分区的重要性


    之前用的文件系统是initramfs的,这种文件系统是编译进内核里的,而开机之后内核是写在内存中的,所以每次掉电之后写进文件系统中的东西都会丢失。所以决定换成ubifs的文件系统。这种文件系统是跟内核分开烧录的,开机之后由内核自动挂载。文件系统在nandflash中,掉电之后不会丢失。因为内核跟文件系统是分开的,每次开机的时候u-boot就要告诉内核文件系统在哪个位置。并且,在写文件系统的时候一定要写对位置。

    我在烧录文件系统的时候遇到了一个问题困扰了我很久:每次烧录完内核烧录完文件系统之后要进入内核就会死在一个找不到文件系统的地方,报错如下:

    ip_set: protocol 6
    IPVS: Registered protocols (TCP, UDP, AH, ESP)
    IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
    IPVS: Creating netns size=1008 id=0
    IPVS: ipvs loaded.
    IPVS: [rr] scheduler registered.
    IPVS: [wrr] scheduler registered.
    IPVS: [lc] scheduler registered.
    IPVS: [wlc] scheduler registered.
    IPVS: [lblc] scheduler registered.
    IPVS: [lblcr] scheduler registered.
    IPVS: [dh] scheduler registered.
    IPVS: [sh] scheduler registered.
    IPVS: [sed] scheduler registered.
    IPVS: [nq] scheduler registered.
    ip_tables: (C) 2000-2006 Netfilter Core Team
    ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
    arp_tables: (C) 2002 David S. Miller
    TCP cubic registered
    NET: Registered protocol family 17
    lib80211: common routines for IEEE802.11 drivers
    Registering the dns_resolver key type
    drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
    UBIFS error (pid 1): check_lpt_type: invalid type (15) in LPT node type 2
    List of all partitions:
    1f00 1024 mtdblock0 (driver?)
    1f01 15360 mtdblock1 (driver?)
    1f02 65536 mtdblock2 (driver?)
    1f03 81920 mtdblock3 (driver?)
    1f04 49152 mtdblock4 (driver?)
    1f05 262144 mtdblock5 (driver?)
    No filesystem could mount root, tried: ubifs
    Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
    Backtrace:
    [<c003b2cc>] (dump_backtrace+0x0/0x110) from [<c04151c0>] (dump_stack+0x18/0x1c)
    r6:00008000 r5:c38a5006 r4:c05a7480 r3:c057e274
    [<c04151a8>] (dump_stack+0x0/0x1c) from [<c0415220>] (panic+0x5c/0x17c)
    [<c04151c4>] (panic+0x0/0x17c) from [<c0008de0>] (mount_block_root+0x1c8/0x208)
    r3:c3819f54 r2:80000000 r1:c3819f78 r0:c04fc2c7
    r7:c002677c
    [<c0008c18>] (mount_block_root+0x0/0x208) from [<c0009080>] (prepare_namespace+0x94/0x1b4)
    [<c0008fec>] (prepare_namespace+0x0/0x1b4) from [<c00089d4>] (kernel_init+0xe4/0x118)
    r5:c0025f50 r4:c05a6d60
    [<c00088f0>] (kernel_init+0x0/0x118) from [<c004d8ac>] (do_exit+0x0/0x624)

    很明显是内核找不到文件系统,于是我去检查了我的内核分区表如下:

     1 static struct mtd_partition smdk_default_nand_part[] = {
     2     [0] = {
     3         .name   = "u-boot",
     4         .size   = SZ_1M,
     5         .offset = 0,
     6     },
     7     [1] = {
     8         .name   = "kernel",
     9         .offset = MTDPART_OFS_NXTBLK,
    10         .size   = SZ_1M*15,
    11     },
    12     [2] = {
    13         .name   = "rootfs",
    14         .offset = MTDPART_OFS_NXTBLK,
    15         .size   = SZ_1M*64,
    16     },
    17     [3] = {
    18         .name   = "apps",
    19         .offset = MTDPART_OFS_NXTBLK,
    20         .size   = SZ_1M*80,
    21     },
    22     [4] = {
    23         .name   = "data",
    24         .offset = MTDPART_OFS_NXTBLK,
    25         .size   = SZ_1M*48,
    26     },
    27     [5] = {
    28         .name   = "info",
    29         .size   = SZ_1M * 48,
    30         .size   = MTDPART_OFS_NXTBLK,
    31     },
    32 };

    而我的bootargs跟分区表也是对应的:

    bootargs_ubifs  console=ttyS0,115200 mem=64M ubi.mtd=2 root=ubi0:rootfs rootwait rootfstype=ubifs rw

    那么内核为什么找不到文件系统呢。最后突然想到会不会是写的时候出错导致文件系统没有写对,于是去检查了写的命令,果然发现是写的地方出错了。

    我在内核中给文件系统的分区在2分区,分区大小为64M,从16M——80M。所以写的过程应该是这样的:tftp到30008000的位置,然后将16M——80M即1000000——6000000的位置擦除,然后将30008000位置的东西写到1000000的地方,写1000000的大小。

    tftp 30008000 rootfs-ubifs.bin;nand erase 1000000 6000000;nand write 30008000 1000000 1000000

    写完之后boot进入内核成功!

    在烧录文件系统的时候要注意几个地方:

    (1)烧录文件系统之前一定要把要写入的分区整个分区给擦除掉。

    (2)bootargs要指定对正确的分区。

    (3)nand write写的时候要写对位置。

  • 相关阅读:
    TSQL入门(msdn)
    在代码中,获取Entity Framework生成的TSQL查询语句
    Code First(一)
    UDPClient的用法
    Building Applications that Can Talk(转)
    Asynchronous Web and Network Calls on the Client in WPF(摘录)
    DropBox能正常使用了
    显示GIF图标报错:“A generic error occurred in GDI+.”
    第 2 篇Scrum 冲刺博客
    第 1 篇 Scrum 冲刺博客
  • 原文地址:https://www.cnblogs.com/xiaohexiansheng/p/5722326.html
Copyright © 2020-2023  润新知