第一次挂载jffs2文件系统,出现:Node header CRC failed at
制作jffs2文件系统,kernel配置
一、烧写一个支持flash擦写的内核1.配置内核JFFS2_FS=yJFFS2_FS_DEBUG=0JFFS2_FS_WRITEBUFFER=yMTD_CONCAT=y2.配置用户应用MTD utils->[*]mtd-utils[*]erase[*]eraseall3. 编译并烧写系统二、编译kernel和制作jffs2文件系统1. 配置内核INITRAMFS_SOURCE 清空该配置项内容SYSFS=y2.修改source/linux-2.6.36.x/drivers/mtd/ralink/ralink_spi.c80-83行增加内容如下:3.修改source/linux-2.6.36.x/drivers/mtd/maps/ralink-flash.h修改30-32行内容如下:内核分配1.5M flash,其余全部给文件系统,实际做错来内核1.4M4.修改启动参数source/linux-2.6.36.x/arch/mips/ralink/cmdline.c 51行console=ttyS1,57600n8 root=/dev/mtdblock5 rootfstype=jffs2 rw5.编译内核6.mkfs.jffs2工具安装a)lzo-2.06.tar.gz ./configure && make && make installb)e2fsprogs-1.42.tar.gz ./configure && make && make install &&make install-libsc)yum install libacl-develd)mtd-utils-1.4.8.tar.gz make && make install7.制作jffs2文件系统镜像mkfs.jffs2 -s 0x1000 -e 0x10000 -p 0xe30000 -d romfs/ -o jffs.img 注:0xe30000为指定文件系统大小,我在这里指定剩余flash大小,除非对flash增加分区,否则使用剩余flash大小,以免flash浪费三、刷kernel 和jffs.img1.启动第一次刷进的系统,并使用tftp将kernel 和jffs.img 上传内存2. 擦除flasheraseall /dev/mtd43.写kerneldd if=kernel of=/dev/mtd44.写文件系统dd if=jffs.img of=/dev/mtd4 bs=65536 seek=24重启系统ok~~~~增加或删除文件后需要执行sync命令方可生效,文件大时虽然命令返回,但仍需等待一会,方可生效。
诺西eNodeB常见故障处理说明书
诺西eNodeB常见故障处理说明书诺西常见故障标准化处理说明书1 诺西Flexi BTS 7650告警处理<告警名称>BASE STATION FAULTY<处理方法>按照故障可能的原因分类,分别列出处理方法如下:1.1 BTS Blocked详细信息Fault name:BTS Blocked(0050)问题描述基站被手动闭锁,系统会上报此告警,需要从site manager登录基站并解锁,解锁过程系统会自动重启基站。
处理方法如图所示,用site manager登录基站后,点击unblock BTS解锁基站,基站重启后告警会自动消除。
1.2 BTS internal SW management problem详细信息Fault name:BTS internal SW management problem(3090)问题描述这个告警的原因是系统检测到文件或者软件错误,可能原因比如远程下发基站参数或者升级软件,但中间的防火墙禁掉某些端口导致基站接收到的文件错误等处理方法1.重启基站;2.重新升级基站软件版本;1.3 Baseband Bus failure详细信息Fault name:Baseband Bus failure(3020)问题描述这个告警的原因是系统检测基站内部基带总线有异常处理方法1.远端重启基站;2.进站检查故障的硬件,尝试调换连线来定位故障位置,更换故障的硬件;1.4 System Module failure详细信息Fault name:System Module failure(3000)问题描述这个告警的原因是系统检测基站系统模块有异常处理方法1.远端重启基站;2.进站检查故障的硬件,尝试调换连线来定位故障位置,更换故障的硬件;1.5 Incompatible SW version detected详细信息Fault name:Incompatible SW version detected(0023/0024)问题描述这个告警的原因是系统检测软件版本不匹配,一般是在硬件更换后产生此告警处理方法新安装或者刚刚完成排障被BBU新检测到的RRU及其他模块,由于没有跟BBU 一起升级,会产生此告警,只要在连接正常的情况下,重新升级基站版本然后重启基站即可,注意RRU 完成升级之后,如果没有配置对应的小区数据,需要手动添加数据配置到该RRU 上。
jffs2常见问题
Question1:JFFS2 error: (1) jffs2_build_inode_pass1: child dir "alsa" (ino #1159) of dir ino #1074 appears to be a hard linkJFFS2 error: (1) jffs2_build_inode_pass1: child dir "l" (ino #1170) of dir ino #1075 appears to be a hard link原由: flash没有erase彻底.VFS: Mounted root (jffs2 filesystem) on device 31:1.Freeing init memory: 136KJFFS2 notice: (1) check_node_data: wrong data CRC in data node at 0x0f0a7f78: read 0x4462b066, calculated 0x48ea177f.JFFS2 error: (488) jffs2_do_read_inode_internal: Argh. Special inode #139 with mode 0x61b0 had more than one nodeiget() failed for ino #139mknod: /dev/null: File existsPopulating /dev using udev: udevd (499): /proc/499/oom_adj is deprecated, please use /proc/499/oom_score_adj instead.JFFS2 error: (500) jffs2_do_read_inode_internal: Argh. Special inode #1123 with mode 0x21b0 had more than one nodeiget() failed for ino #1123Question2:jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x2b10 insteadmkfs.jffs2 -s 的参数问题对照FLASH的大小再重新生成镜像文件过即可The answer this means that the data on your flash device is not a valid JFFS2 file system. There is no single solution for this problem, but we will try to provide you some ideas how to fix this.The first question you should try to answer is "why the data on my flash device is incorrect so that JFFS2 rejects to deal with it?". There are may be a plenty of reasons, e.g.:1. you flash driver is severely buggy so it reads trash instead of valid data;2. you flashed some trash instead of a valid JFFS2 image;3. you did not manage to flash JFFS2 image correctly so that you ended up withgarbage on your flash, although the original image was perfectly fine;4. you forgot to erase your flash before flashing it, etc.Anyways, JFFS2 wouldn't complain if it was able to find correct data. As it does complain, there is something wrong with the data it reads.One common mistake is to use /dev/mtdX or /dev/mtdblockX devices to flash JFFS2 images on NAND flashes. E.g.cp jffs2_fs.img /dev/mtd2This is incorrect because when dealing with NAND flashes one has to skip bad eraseblocks and write only in NAND page size chunks. Please, use the nandwrite utility instead.Also please, do not forget to erase your flash before flashing the image. You may use the flash_eraseall utility for this. And it makes sense to make sure the erase functionality actually works by reading the erased MTD device back and checking that only 0xFF bytes were read.You may try to check if your flash driver works correctly and if you flashed the file system image correctly by means of reading the flash back after you have flashed your image, and compare the read image with the original one. Please, use the nandread utility to read from NAND flashes.You can also do the following experiment to make sure JFFS2 works well. Erase your MTD device and mount it to JFFS2. You will end up with an empty file system. Copy some files to the JFFS2 file system and unmount it. Then mount it again and see if it mounts without problems. If it does, this is most probably not a JFFS2 bug.Question3:Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXXThis message is generated if a block of data is partially written. It is generally not a sign of any problem.Question4:Name CRC failed on node at 0x00b620c8: Read 0x640c8ca3, calculated 0x795111fe重启,则不会有如上CRC错误信息。
JFFS2文件系统分析报告
JFFS2文件系统分析报告本文在深入研究jffs2源代码基础上,对JFFS2文件系统的实现机制进行了分析,包括关键的数据结构及其之间的联系,文件系统的注册和挂载,以及其他主要的操作流程。
1 JFFS2层次结构在Linux系统中,JFFS2文件系统处于虚拟文件系统层VFS与存储技术设备层MTD之间,如图1所示。
VFS为内核中的各种文件系统提供一个统一的抽象层,并为上层用户提供具有统一格式的接口函数;MTD子系统整合底层芯片驱动,为上层文件系统提供了统一访问MTD设备(主要是NOR闪存和NAND闪存等设备)的接口。
JFFS2在内存中建立超级块信息jffs2_sb_info管理文件系统操作,建立索引节点信息jffs2_inode_info管理打开的文件。
VFS层的超级块super_block和索引节点inode分别包含JFFS2文件系统的超级块信息jffs2_sb_info和索引节点信息jffs2_inode_info,它们是JFFS2和VFS间通信的主要接口。
JFFS2文件系统的超级块信息jffs2_sb_info包含底层MTD设备信息mtd_info指针,文件系统通过该指针访问MTD设备,实现JFFS2和底层MTD设备驱动之间的通信。
图1 JFFS2文件系统层次2 JFFS2数据实体JFFS2在Flash上只存储两种类型的数据实体,分别为jffs2_raw_inode和jffs2_raw_ dirent。
■jffs2_raw_dirent:包括文件名、ino号、父节点ino号、版本号、校验码等信息,它用来形成整个文件系统的层次目录结构。
■jffs2_raw_inode:包括文件ino号、版本号、访问权限、修改时间、本节点所包含的数据文件中的起始位置及本节点所包含的数据大小等信息,它用来管理文件的所有数据。
一个目录文件由多个jffs2_raw_dirent组成。
而普通文件,符号链接文件,设备文件,FIFO文件等都由一个或多个jffs2_raw_inode数据实体组成。
JFFS2文件系统介绍
JFFS2文件系统及新特性介绍(reset)成逻辑1。
D)闪存的使用寿命是有限的。
具体来说,闪存的使用寿命是由擦写块的最大可擦写次数来决定的。
超过了最大可擦写次数,这个擦写块就成为坏块(bad block)了。
因此为了避免某个擦写块被过度擦写,以至于它先于其他的擦写块达到最大可擦写次数,我们应该在尽量小的影响性能的前提下,使擦写操作均匀的分布在每个擦写块上。
这个过程叫做磨损平衡(wear leveling)。
NOR flash与NAND flash的不同之处:A)NOR flash读/写操作的基本单位是字节;而NAND flash又把擦写块分成页(page),页是写操作的基本单位,一般一个页的大小是512或2K个字节。
对于一个页的重复写操作次数是有限制的,不同厂商生产的NAND flash有不同的限制,有些是一次,有些是四次,六次或十次。
B)按照现在的技术水平,一般来说NOR flash擦写块的最大可擦写次数在十万次左右,NAND flash擦写块的最大可擦写次数在百万次左右。
1.2闪存转换层将磁盘文件系统(ext2,FAT)运行在闪存上的很自然的方法就是在文件系统和闪存之间提供一个闪存转换层(Flash Translation Layer),它的功能就是将底层的闪存模拟成一个具有512字节扇区大小的标准块设备(block device)。
对于文件系统来说,就像工作在一个普通的块设备上一样,没有任何的差别。
图一一个闪存转换层的最简单的实现就是将模拟的块设备一对一的映射到闪存上。
举例来说,当上层的文件系统要写一个块设备的扇区时,闪存转换层要做下面的操作来完成这个写请求:1将这个扇区所在擦写块地数据读到内存中,放在缓存(buffer)中2将缓存中与这个扇区对应的内容用新的内容替换掉3对该擦写块执行擦写操作4将缓冲中的数据写回该擦写块这种实现方式的缺点是很明显的:1效率低,对一个扇区的更新要重写整个擦写块上的数据,造成数据带宽很大的浪费。
在嵌入式Linux系统中挂载 jffs2 根文件系统
在嵌入式Linux系统中挂载 jffs2 根文件系统我已经在《构建基本的嵌入式Linux根文件系统》介绍了如何建立基本的嵌入式Linux根文件系统,并用NFS挂载成功。
如果要以挂载JFFS2格式的根文件系统,其基本方法就是将这个建立好的根文件系统制作成jffs2镜像,烧到FLASH中,改改Linux的启动参数即可。
具体做法如下:一、宿主机HOST编译制做MTD工具从/下载mtd-utils 的tarball,可以下载最新的。
然后解压,并在其目录下make 就好!二、制作根文件系统的JFFS2镜像。
各参数的意义:(1)-r :指定要做成image的源資料夾.(2)-o : 指定輸出image檔案的文件名.(3)-e : 每一塊要抹除的block size,預設是64KB.要注意,不同的flash, 其block size會不一樣.我的是三星的K9F1208U0B.(4)--pad (-p): 用16進制來表示所要輸出檔案的大小,也就是root.jffs2的size。
很重要的是, 為了不浪費flash空間, 這個值最好符合flash driver所規劃的區塊大小.以我的板子來說,就是5MB.(5)如果挂载后会出现类似:CLEANMARKER node found at 0x0042c000 has totlen 0xc != normal 0x0 的警告,则加上-n 就会消失。
(6) 还有的选项,自己看帮助!-h三、烧写JFFS2镜像到NAND FLASH。
将rootfs.jffs2拷贝到NFS共享目录,然后启动开发板。
具体操作看我的开发板信息就好了:NAND: NAND flash probing at 0x4E00000064 MBIn: serialOut: serialErr: serialHit any key to stop autoboot: 0[Tekkaman2440]#nfs 0x30008000192.168.1.22:/home/tekkamanninja/working/nfs/rootfs.jffs2dm9000 i/o: 0x20000300, id: 0x90000a46MAC: 08:08:08:08:12:27operating at 100M full duplex modeFile transfer via NFS from server 192.168.1.22; our IP address is 192.168.1.2Filename '/home/tekkamanninja/working/nfs/rootfs.jffs2'.Load address: 0x30008000Loading:################################################################# ########################################################## ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# #########################################################doneBytes transferred = 5242880 (500000 hex)[Tekkaman2440]#nand erase 0xa00000 0x500000NAND erase: device 0 offset 10485760,size 5242880 ...OK[Tekkaman2440]#nand write 0x30008000 0xa00000 0x500000NAND write: device 0 offset 10485760,size 5242880 ...5242880 bytes written: OK[Tekkaman2440]#setenv bootargs noinitrd root=/dev/mtdblock4 rootfstype=jffs2 rw console=ttySAC0,115200 init=/linuxrc mem=64M[Tekkaman2440]#bootdm9000 i/o: 0x20000300, id: 0x90000a46MAC: 08:08:08:08:12:27operating at 100M full duplex modeFile transfer via NFS from server 192.168.1.22; our IP address is 192.168.1.2Filename '/home/tekkamanninja/working/nfs/zImage.img'.Load address: 0x30008000Loading:################################################################# ########################################################## ################################################################# ################################################################# ############################################################ doneBytes transferred = 1600564 (186c34 hex)## Booting image at 30008000 ...Image Name: tekkamanninjaCreated: 2008-02-15 2:16:28 UTCImage Type: ARM Linux Kernel Image (uncompressed)Data Size: 1600500 Bytes = 1.5 MBLoad Address: 30008000Entry Point: 30008040Verifying Checksum ... OKXIP Kernel Image ... OKStarting kernel ...Uncompressing Linux.............................................................. .......................................... done, booting the kernel. Linux version 2.6.24 (tekkamanninja@Tekkaman-Ninja)(gcc version4.1.1) #1 Fri Feb 15 10:15:36 CST 2008CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177Machine: Tekkaman2440Memory policy: ECC disabled, Data cache writebackCPU S3C2440A (id 0x32440001)S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz S3C24XX Clocks,(c) 2004 Simtec ElectronicsCLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL onCPU0: D VIVT write-back cacheCPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists in Zone order,mobility grouping on.Total pages:16256 Kernel command line: noinitrd root=/dev/mtdblock4 rootfstype=jffs2 rw console=ttySAC0,115200 init=/linuxrc mem=64Mirq: clearing pending ext status 00000200irq: clearing subpending status 00000003irq: clearing subpending status 00000002PID hash table entries: 256 (order: 8, 1024 bytes)timer tcon=00500000, tcnt a4ca, tcfg 00000200,00000000, usec 00001e57 Console: colour dummy device 80x30console [ttySAC0] enabledDentry cache hash table entries: 8192 (order: 3, 32768 bytes)Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)Memory: 64MB = 64MB totalMemory: 61464KB available (2960K code, 306K data, 120K init) Mount-cache hash table entries: 512CPU: Testing write buffer coherency: oknet_namespace: 64 bytesNET: Registered protocol family 16S3C2410 Power Management,(c) 2004 Simtec ElectronicsS3C2440: Initialising architectureS3C2440: IRQ SupportS3C2440: Clock Support, DVS offS3C24XX DMA Driver,(c) 2003-2004,2006 Simtec ElectronicsDMA channel 0 at c4800000, irq 33DMA channel 1 at c4800040, irq 34DMA channel 2 at c4800080, irq 35DMA channel 3 at c48000c0, irq 36usbcore: registered new interface driver usbfsusbcore: registered new interface driver hubusbcore: registered new device driver usbNET: Registered protocol family 2IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes)TCP: Hash tables configured (established 2048 bind 2048)TCP reno registeredNetWinder Floating Point Emulator V0.97 (double precision)JFFS2 version 2.2.(NAND)©; 2001-2006 Red Hat,Inc.fuse init (API version 7.9)yaffs Feb 15 2008 10:10:34 Installing.io scheduler noop registeredio scheduler anticipatory registered (default)io scheduler deadline registeredio scheduler cfq registeredSerial:8250/16550 driver $Revision:1.90 $ 4 ports,IRQ sharing enabled s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: module loadeddm9000 Ethernet Drivereth0: dm9000 at f6100300,f6100304 IRQ 51 MAC: 08:08:08:08:12:27 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xxS3C24XX NAND Driver,(c) 2004 Simtec Electronicss3c2440-nand s3c2440-nand: Tacls=1, 9ns Twrph0=4 39ns, Twrph1=1 9ns NAND device: Manufacturer ID: 0xec, Chip ID: 0x76 (Samsung NAND 64MiB 3,3V 8-bit)Scanning device for bad blocksBad eraseblock 3579 at 0x037ec000Creating 7 MTD partitions on "NAND 64MiB 3,3V 8-bit":0x00000000-0x00020000 :"U-Boot-1.3.1"0x00020000-0x00030000 :"U-Boot-1.3.1 Parameter"0x00030000-0x00500000 :"Linux2.6.24 Kernel"0x00500000-0x00a00000 :"Root(cramfs)"0x00a00000-0x00f00000 : "Root(JFFS2)"0x00f00000-0x01400000 :"Root(YAFFS)"0x01400000-0x04000000 :"DATA"usbmon: debugfs is not availables3c2410-ohci s3c2410-ohci: S3C24XX OHCIs3c2410-ohci s3c2410-ohci:new USB bus registered,assigned bus number 1s3c2410-ohci s3c2410-ohci: irq 42, io mem 0x49000000usb usb1: configuration #1 chosen from 1 choicehub 1-0:1.0: USB hub foundhub 1-0:1.0: 2 ports detectedmice: PS/2 mouse device common for all miceS3C24XX RTC,(c) 2004,2006 Simtec Electronicss3c2410-rtc s3c2410-rtc: rtc disabled, re-enablings3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0s3c2440-i2c s3c2440-i2c: slave address 0x10s3c2440-i2c s3c2440-i2c: bus frequency set to 98 KHzs3c2440-i2c s3c2440-i2c: i2c-0: S3C I2C adapterS3C2410 Watchdog Timer,(c) 2004 Simtec Electronicss3c2410-wdt s3c2410-wdt:watchdog inactive,reset disabled,irq enabled TCP cubic registeredNET: Registered protocol family 1RPC: Registered udp transport module.RPC: Registered tcp transport module.s3c2410-rtc s3c2410-rtc: setting system clock to 2008-02-17 12:46:08 UTC (1203252368)VFS: Mounted root (jffs2 filesystem).Freeing init memory: 120Kinit started: BusyBox v1.9.1 (2008-02-16 15:04:08 CST)starting pid 779, tty '':'/etc/init.d/rcS'。
JFFS2文件系统的制作
使用新的busybox-1.13.3制作jffs2文件系统由于之前使用的文件系统中的busybox是1.5版本,结果很多工具都没有完善,这一次,在上下载了当前的最新稳定版本,busybox-1.13.3来制作,总算搞定了,但也出现了一些问题,贴出我的过程跟大家分享一下,也给有需要的人一点帮助,希望如此。
全文如下:2009-3-26陈纪煌今天尝试了移植新的文件系统,使用的是busybox-1.13.3稳定版本由于之前所使用的版本是busybox-1.5.0,结果发现很多东西无法支持,比如nfs无法挂在,并且clear等工具无法正常使用所以下了一个新的版本进行尝试1.解压该包tar xf busybox-1.13.3.tar.bz2cd busybox-1.13.32.修改Makefile找到CROSS_COMPILE ?=修改为CROSS_COMPILE ?=arm-linux-找到ARCH ?= $(SUBARCH)修改为ARCH ?= arm3.进行默认配置make defconfig4.对配置信息进行修改make menuconfig检查Miscellaneous Utilities--->taskset 是否已经去除同时设置如下:Busybox Settings --->Build Options --->[*]Build BusyBox as a static binry (no shared libs)()Cross Compiler prefix=/usr/local/arm/3.4.1/bin/Installation Options --->[*]Don't use /usrBusyBox installation=${PROJECT}/rootfs/rootfs_1.13这几个设置对于之前做过相关工作的人来说是比较熟悉的,都很容易知道为何如此做。
JFFS2文件系统挂载过程优化的分析
JFFS2文件系统挂载过程优化的分析报告一问题描述在上电启动优化中发现Linux系统下挂载JFFS2文件系统耗时较长,以128M的NOR FLASH 为例,用时接近20秒。
后续单板的FLASH容量为256M,时间会更长。
如此长的挂载时间,会大增加系统的上电启动时间。
希望能对mount功能或JFFS2文件系统做适当优化,将256M FLASH的挂载时间降到3~5秒内,优化时需要同时保证文件系统的可靠性和读写速度,要保证兼容优化前的文件系统。
root@CMM:/$ time mount -t jffs2 /dev/mtdblock1 /FLASH0real 0m 19.83suser 0m 0.00ssys 0m 19.73s二问题分析与磁盘文件系统不同,JFFS2文件系统不在FLASH设备上存储文件系统结构信息,所有的信息都分散在各个数据实体节点之中,在挂载文件系统的时候,需扫描整个Flash设备,从中建立起文件系统在内存中的映像,系统在运行期间,就利用这些内存中的信息进行各种文件操作。
这就造成了JFFS2文件系统挂载时间过长,尤其是FLASH比较大,文件比较多的情况下。
擦除块小结(erase block summary)补丁可以提高JFFS2文件系统的挂载速度,它最基本的思想就是用空间来换时间。
具体来说,就是将擦除块每个节点的原数据信息写在这个擦除块最后的固定位置,当JFFS2挂载的时候,对每个擦除块只需要读取这个小结节点。
同时该补丁具有一定的稳定性和兼容性。
●稳定性:If the summary node is missing, maybe because of a system power-down before it could be written to flash, nothing bad happens - JFFS2 just falls back to scanning the whole block as it would have done before.●兼容性:The JFFS2 image produced by sumtool is also usable with previous kernel because the summary node is JFFS2_FEATURE_RWCOMPAT_DELETE.(当不支持擦除块小结特性的JFFS2文件系统发现了一个属性是JFFS2_FEATURE_RWCOMPAT_DELETE的节点时,在垃圾回收的时候,该节点可以被删除)三原理介绍在每个擦除块的末尾,有一个8 byte长的jffs2_sum_marker节点,该sum_marker节点记录summary node信息的存储位置,summary node可以由文件系统在写操作的过程中自动产生。
jffs2启动的常见的问题
jffs2启动的常见的问题Q:在启动过程中出现at91sam user.warn kernel: Empty flash at 0x00f0fffc ends at 0x00f10000问题A:在mkfs.jffs2的时候,加上-e 0x20000指定擦除块的大小。
-e是指定擦除块的大小,我们使用的nandflash的块大小为128K字节,因此-e后的参数为(128*1024)10=(20000)16。
Q:启动的时候出现CLEANMARKER node found at 0x00f10000 has totlen 0xc != normal 0x0问题。
A:在mkfs.jffs2的时候,加上-n选项。
-n, --no-cleanmarkers。
指明不添加清楚标记(nand flash 有自己的校检块,存放相关的信息。
)如果挂载后会出现类似:CLEANMARKER node found at 0x0042c000 has totlen 0xc != normal 0x0 的警告,则加上-n 就会消失。
Q:解决jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01649298: 0xa25e instead问题的方法A:在mkfs.jffs2的时候加上-s 2048(页大小,由芯片决定)以及-l(小端模式)两个选项。
-s是指明页的大小,我们使用的nandflash 的页的大小为2048字节。
-l指明为小端模式,一般嵌入式下均为小端模式。
说明:1、在文件系统制作的过程,均需要使用root用户权限;2、一般嵌入式下只有root用户登录,因此文件系统中的所有文件都需要具有root可执行权限,如果用其他用户登录,请保证文件系统中文件(特别是自己添加的文件)的相应可执行权限。
NSC2200E.常见问题解决方法
NSC2200EFAQ本文档总结了NSC2200E在使用过程中可能碰到的常见问题以及解决方法.更新人历史更新时间备注严涛松 2012-06-27 建立文档严涛松 2012-12-28 更新严涛松 2012-5-3 更新严涛松 2015-11-23 更新目录Q0. 配置原则 -------------------------------------------------------------------------------------------------------------------- 4 Q1. 配置文件下载不了,提示“配置规约(XXX)装置不支持,无法下载”,或者提示“配置规约(XXX)版本与装置规约(XXX)版本不一致,无法下载 --------------------------------------- 4 Q2. 我要通过路由器和远方的设备进行通信,怎么配置路由信息?------------------------------------------------- 4 Q3. 对方是使用IEC103通信,可是2200E里面有很多比如IEC103,ZD103等等,我应该使用那个?---- 5 Q4. 公用信号中的通信状态和realmonitor中显示的设备实际通信状态不对应?这个有可能是什么情况?- 5 Q5. 为什么下载了最新程序,但是面板上的LED都不闪,液晶也没有任何字符,程序没有运行吗?-------- 5 Q6. 为什么我的程序只有LCM没有能够下载成功,而其他程序都下载成功了?-------------------------------- 5 Q7. 为什么NSC200NT或者NS2005后台数据库或者画面的一个信号位置和realmonitor中不一样?会不会是NSC2200E把信号丢失了? ----------------------------------------------------------------------------------------------- 6 Q8. 当其中一台NSC2200E掉电后,另外一台切换为主机的时间太慢了,有没有硬双机切换? ----------- 6 Q9. 为什么下载了最新程序,却发现NSC2200E不停的重启,这是怎么回事?我该怎么处理? ----------- 6 Q10. 某个串口通道下面,配置了5台AREV A装置,其中两台通不上,前置机也在发送报文,而且只要其中一台一接通信线,那么所有的装置通信都断了。
Linux系统中的mount挂载磁盘命令使用教程
Linux系统中的mount挂载磁盘命令使⽤教程功能:加载指定的⽂件系统。
语法:mount [-afFhnrvVw] [-L<标签>] [-o<选项>] [-t<⽂件系统类型>] [设备名] [加载点]⽤法说明:mount可将指定设备中指定的⽂件系统加载到Linux⽬录下(也就是装载点)。
可将经常使⽤的设备写⼊⽂件/etc/fstab,以使系统在每次启动时⾃动加载。
mount加载设备的信息记录在/etc/mtab⽂件中。
使⽤umount命令卸载设备时,记录将被清除。
常⽤参数和选项:-a 加载⽂件/etc/fstab中设置的所有设备。
-f 不实际加载设备。
可与-v等参数同时使⽤以查看mount的执⾏过程。
-F 需与-a参数同时使⽤。
所有在/etc/fstab中设置的设备会被同时加载,可加快执⾏速度。
-h 显⽰在线帮助信息。
-L<标签> 加载⽂件系统标签为<标签>的设备。
-l 显⽰已加载的⽂件系统列表(同直接执⾏mount)-n 不将加载信息记录在/etc/mtab⽂件中。
-o<选项> 指定加载⽂件系统时的选项。
有些选项也可在/etc/fstab中使⽤。
这些选项包括:async 以⾮同步的⽅式执⾏⽂件系统的输⼊输出动作。
atime 每次存取都更新inode的存取时间,默认设置,取消选项为noatime。
auto 必须在/etc/fstab⽂件中指定此选项。
执⾏-a参数时,会加载设置为auto的设备,取消选取为noauto。
defaults 使⽤默认的选项。
默认选项为rw、suid、dev、exec、anto nouser与async。
dev 可读⽂件系统上的字符或块设备,取消选项为nodev。
exec 可执⾏⼆进制⽂件,取消选项为noexec。
noatime 每次存取时不更新inode的存取时间。
noauto ⽆法使⽤-a参数来加载。
JFFS2的优缺点
JFFS2 文件系统及新特性介绍简介:JFFS2 是一个开放源码的项目()。
它是在闪存上使用非常广泛的读/写文件系统,在嵌入式系统中被普遍的应用。
这篇文章首先分析了在闪存上使用 JFFS2 的必要性,然后详细的阐述了 JFFS2 实现的内部机制,包括日志结构的文件系统,关键的数据结构,挂载过程和垃圾收集机制。
同时也指出了 JFFS2 的局限性,并介绍了最新的针对 JFFS2 的不足进行改进的补丁程序。
最后对 JFFS3 的设计思想和现在的开发状况给予了简单的介绍。
1.为什么需要 JFFS2这一小节首先介绍了闪存相对于磁盘介质的特别之处,然后分析了将磁盘文件系统运行在闪存上的不足,同时也给出了我们使用 JFFS2 的理由。
1.1 闪存(Flash Memory) 的特性和限制这里所介绍的闪存的特性和限制都是从上层的文件系统的角度来看的,而不会涉及到具体的物理特性。
总的来说,有两种类型的 flash memory: NOR flash 和NAND flash. 先介绍一下这两种闪存所具有的共同特性。
A) 闪存的最小寻址单位是字节(byte),而不是磁盘上的扇区(sector)。
这意味着我们可以从一块闪存的任意偏移(offset)读数据,但并不表明对闪存写操作也是以字节为单位进行的。
我们会在下面的阐述中找到答案。
B) 当一块闪存处在干净的状态时(被擦写过,但是还没有写操作发生),在这块flash上的每一位(bit)都是逻辑1。
C) 闪存上的每一位(bit)可以被写操作置成逻辑0。
可是把逻辑 0 置成逻辑 1 却不能按位(bit)来操作,而只能按擦写块(erase block)为单位进行擦写操作。
擦写块的大小从 4K 到128K 不等。
从上层来看,擦写所完成的功能就是把擦写块内的每一位都重设置(reset)成逻辑 1。
D) 闪存的使用寿命是有限的。
具体来说,闪存的使用寿命是由擦写块的最大可擦写次数来决定的。
jffs2文件系统
[*] Caching block device access to MTD devices
File systems --->
Miscellaneous filesystems --->
nand write.jffs2:向Nand Flash写入数据,如果NandFlash相应的区域有坏块,可以跳过坏块。
nand read:读取Nand Flash相应区域的数据,如果NandFlash相应的区域有坏块,则直接报错。
nand read.jffs2:读取Nand Flash相应区域的数据,如果NandFlash相应的区域有坏块,直接跳过坏块。
#cd zlib-1.2.3
#./configure
#make
#make install
完成此步骤后,系统中就有了mkfs.jffs2的工具。注意:这个工具不同于mkfs.ext2工具,它只能制作相应的JFFS2文件系统的镜像,而不具有进行格式化的功能,而mkfs.ext2具备这以上两种功能。然后用这个工具就可以制作JFFS2文件系统的镜像了。
具体操作及地址请参照本空间 Linux 系统的烧写
********************************************************
#nand erase 0x500000 0x3e00000
#tftp 0x30008000 rootfs.jffs2
#nand write.jffs2 0x30008000 0x500000 0x250000//(必须是rootfs.jffs2的实际大小。如果是你写的小了,那么分区的其余部分JFFS2文件系统将无法识别)。
第一次挂载jffs2文件系统,出现:NodeheaderCRCfailedat
第一次挂载jffs2文件系统,出现:NodeheaderCRCfailedat第一次挂载jffs2文件系统,出现:Node header CRC failed at 使用的bootloader:redbootkernel版本:2.6.29flash类型:NOR FLASH.制作jffs2的命令:mkfs.jffs2 -U -d /mnt/winF/tet/romfs -D devtable.jffs2.txt -l -e 0x10000 -p -n -o /tftpboot/jffs2fs.img"-e":表示flash的擦除块大小为0x10000,这个值很重要,可以从datasheet中得到。
"-p":Pad output to SIZE bytes with 0xFF. If SIZE is not specified, the output is padded to the end of the final erase block.烧写命令:load -r -v -h 172.21.73.101 -b 0x8000 kernel.lzofis create -b 0x8000 -l 0x200000 -s 0x200000 -f 0x7F060000 -e 0x8000 kernel.lzoload -r -v -h 172.21.73.101 -b 0x100000 jffs2fs.imgfis write -b 0x100000 -f 0x7F260000 -l 0x250000fis create -f 0x7F260000 -l 0x590000 jffs2.imgreset问题描述:第一次启动,会出现CRC错误信息,如下:Shell invoked to run file: /etc/rcWelcome to____ _ _/ __| ||_|_ _| | | | _ ____ _ _ _ _| | | | | | || | _ \| | | |\ \/ /| |_| | |__| || | | | | |_| |/ \| ___\____|_||_|_| |_|\____|\_/\_/| ||_| ADVANTECH eAutomationFor further information check:/doc/3c11353981.html,//doc/3c11353981.html,/eAutomation/ Execution Finished, ExitingSash command shell (version 1.1.1)/> JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06ddc8.{ff5c,ff5c,ff5cff5c,6cedd300}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06c8c4. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06b3c0. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0006d394: read 0xc96c7e1f, calculated 0xc6974f8f.JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0006be3c: read 0xfaffca56, calculated 0x4e72e8e5.JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x071460. {ff1c,ff1c,ff1cff1c,ff1cff1c}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x0709ac: read 0x8db9f359, calculated 0x22676b8JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06fea4. {ff1c,ff1c,ff1cff1c,ff1cff1c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06f3b4. {1985,e002,0000df5e,a5032844}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x06e91c: read 0x603ebf95, calculated 0x28f62bdbJFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x00071d6c: read 0xe3e40d9c, calculated 0x3b79fefa.JFFS2 warning: (164) jffs2_do_read_inode_internal: Truncating ino #29 to 23732 bytes failed because it only had 12288 bytes to start with!JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0007c694: read 0xe9808a11, calculated 0x98c8ae6e.JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x00076ba0: read 0x8207a914, calculated 0xa68949a.0x090240. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08dc84. {ff1c,ff1c,ff1cff1c,ff1cff1c}Node totlen on flash (0xdf1edf1e) != totlen from node ref (0x000009d8)JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08d1e8. {1985,e002,ff5cff5c,415e1f8f}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x08c7b4: read 0x62c24375, calculated 0x4b07ea0JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08b19c./>重启,则不会有如上CRC错误信息。
jffs2常见问题
Question1:JFFS2 error: (1) jffs2_build_inode_pass1: child dir "alsa" (ino #1159) of dir ino #1074 appears to be a hard linkJFFS2 error: (1) jffs2_build_inode_pass1: child dir "l" (ino #1170) of dir ino #1075 appears to be a hard link原由: flash没有erase彻底.VFS: Mounted root (jffs2 filesystem) on device 31:1.Freeing init memory: 136KJFFS2 notice: (1) check_node_data: wrong data CRC in data node at 0x0f0a7f78: read 0x4462b066, calculated 0x48ea177f.JFFS2 error: (488) jffs2_do_read_inode_internal: Argh. Special inode #139 with mode 0x61b0 had more than one nodeiget() failed for ino #139mknod: /dev/null: File existsPopulating /dev using udev: udevd (499): /proc/499/oom_adj is deprecated, please use /proc/499/oom_score_adj instead.JFFS2 error: (500) jffs2_do_read_inode_internal: Argh. Special inode #1123 with mode 0x21b0 had more than one nodeiget() failed for ino #1123Question2:jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000024: 0x2b10 insteadmkfs.jffs2 -s 的参数问题对照FLASH的大小再重新生成镜像文件过即可The answer this means that the data on your flash device is not a valid JFFS2 file system. There is no single solution for this problem, but we will try to provide you some ideas how to fix this.The first question you should try to answer is "why the data on my flash device is incorrect so that JFFS2 rejects to deal with it?". There are may be a plenty of reasons, e.g.:1. you flash driver is severely buggy so it reads trash instead of valid data;2. you flashed some trash instead of a valid JFFS2 image;3. you did not manage to flash JFFS2 image correctly so that you ended up withgarbage on your flash, although the original image was perfectly fine;4. you forgot to erase your flash before flashing it, etc.Anyways, JFFS2 wouldn't complain if it was able to find correct data. As it does complain, there is something wrong with the data it reads.One common mistake is to use /dev/mtdX or /dev/mtdblockX devices to flash JFFS2 images on NAND flashes. E.g.cp jffs2_fs.img /dev/mtd2This is incorrect because when dealing with NAND flashes one has to skip bad eraseblocks and write only in NAND page size chunks. Please, use the nandwrite utility instead.Also please, do not forget to erase your flash before flashing the image. You may use the flash_eraseall utility for this. And it makes sense to make sure the erase functionality actually works by reading the erased MTD device back and checking that only 0xFF bytes were read.You may try to check if your flash driver works correctly and if you flashed the file system image correctly by means of reading the flash back after you have flashed your image, and compare the read image with the original one. Please, use the nandread utility to read from NAND flashes.You can also do the following experiment to make sure JFFS2 works well. Erase your MTD device and mount it to JFFS2. You will end up with an empty file system. Copy some files to the JFFS2 file system and unmount it. Then mount it again and see if it mounts without problems. If it does, this is most probably not a JFFS2 bug.Question3:Empty flash at 0xXXXXXXXX ends at 0xXXXXXXXXThis message is generated if a block of data is partially written. It is generally not a sign of any problem.Question4:Name CRC failed on node at 0x00b620c8: Read 0x640c8ca3, calculated 0x795111fe重启,则不会有如上CRC错误信息。
Nand flash文件系统总结
NAND flash文件系统目前flash的文件系统比较多,用的比较多的就是JFFS2文件系统。
基于NOR flash上的JFFS2文件系统可以说算是比较成熟了,支持NAND flash的JFFS2也已经发布了。
源代码可以到上面下载。
但是在我的测试过程中,在nand flash上挂接的JFFS2文件系统很不稳定,经常有CRC错误产生。
特别是进行写操作的时候,每次复位都会产生CRC错误,可以说支持NAND flash的JFFS2文件系统目前还不成熟。
而YAFFS文件系统则是专门针对NAND flash的,源代码可以到/yaffs/index.html上下载。
在测试过程中稳定性能比JFFS2文件系统要稳定的多,而且mount分区的时间也比JFFS2文件系统少的多。
用JFFS2 mount一个2m的文件系统大约需要1s。
下面分别介绍在uclinux 下面使用JFFS2和YAFFS文件系统。
1、JFFS2到上面下载最新的MTD和JFFS2压缩包。
压缩包里面还有有关的内核补丁和一些MTD的相关工具。
主要的补丁就是ilookup-2.4.23.patch,因为最新的MTD驱动中要用到一个ilookup()函数。
打完补丁、更新了MTD驱动和JFFS2文件系统之后就开始写自己nand flash驱动了。
如果不想把JFFS2作为根文件系统的话,还需要修改MTD_BLOCK_MAJOR。
驱动可以参考里面的例子,最简单的就是参考spia.c。
写驱动主要工作是定义flash分区结构、定义flash读写地址、写控制flash 的**_hwcontrol()函数。
具体的操作要看所用的nand flash的芯片资料。
相对NOR flash来说驱动要简单多了。
:)改完之后再配置Memory Technology Devices(MTD)下CONFIG_MTD=YCONFIG_MTD_DEBUG=YCONFIG_MTD_DEBUG_VERBOSE=3CONFIG_MTD_PARTITIONS=YCONFIG_MTD_CHAR=YCONFIG_MTD_BLOCK=YNAND Flash Device Drivers下CONFIG_MTD_NAND=Y定义自己的驱动文件File systems下CONFIG_JFFS2_FS=YCONFIG_JFFS2_FS_DEBUG=2CONFIG_JFFS2_FS_NAND=y /*这个是新加的*/在uClinux v1.3.4 Configuration下Flash Tools下CONFIG_USER_MTDUTILS=YCONFIG_USER_MTDUTILS_ERASE=YCONFIG_USER_MTDUTILS_ERASEALL=YCONFIG_USER_MTDUTILS_MKFSJFFS2=Y最后就是辛苦了调试工作了。
华为交换机端口提示CRC错误解决方法
华为交换机端口提示CRC错误解决方法1、问题现象查询端口计数,发现端口有大量的CRC错包,并且不断增长。
[HUAWEI-GigabitEthernet0/0/1]display this interfaceGigabitEthernet0/0/1 current state : UPLine protocol current state : UPUnicast : 888962,Multicast : 0Broadcast : 0,Jumbo : 0CRC : 4782,Giants : 0Jabbers : 0,Throttles : 0Runts : 0,DropEvents : 02、解决方案首先将两端的端口协商模式设置为一致,设置成非自协商模式,或均设置成自协商模式,结果问题依旧。
最后更换网线解决。
3、经验总结CRC错包一般是由于物理链路问题造成的,出现CRC错包后,首先要排除物理链路的影响。
交换机端口错误包分类(1)input errors:各种输入错误的总数,显示范围是20bit。
(2)runts:表示接收到的超小帧个数。
超小帧即接收到的报文小于64字节,且包括有效的CRC字段,报文格式正确。
(3)giants:表示接收到的超长帧个数。
超长帧即接收到的有效报文字节长度大于1518(如果是带tag报文,大于1522),且小于设备能接收的超长帧最大值(1536)。
(4)CRC:表示接收到的CRC校验错误报文个数,即接收到的报文在64~1518(带tag报文是1522)字节范围内,且字节是整数,而CRC校验错误。
(5)frame:也是CRC校验出错报文个数,报文字节不是整数,其他同上。
(6)aborts:表示接收到的非法报文总数,包括:○1报文碎片:小于64字节,且CRC校验错误(报文字节是整数或非整数)。
○2jabber帧:大于1518(tag报文是1522)字节,且CRC校验错误(报文字节是整数或非整数)。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第一次挂载jffs2文件系统,出现:Node header CRC failed at使用的bootloader:redbootkernel版本:2.6.29flash类型:NOR FLASH.制作jffs2的命令:mkfs.jffs2 -U -d /mnt/winF/tet/romfs -D devtable.jffs2.txt -l -e 0x10000 -p -n -o /tftpboot/jffs2fs.img"-e":表示flash的擦除块大小为0x10000,这个值很重要,可以从datasheet中得到。
"-p":Pad output to SIZE bytes with 0xFF. If SIZE is not specified, the output is padded to the end of the final erase block.烧写命令:load -r -v -h 172.21.73.101 -b 0x8000 kernel.lzofis create -b 0x8000 -l 0x200000 -s 0x200000 -f 0x7F060000 -e 0x8000 kernel.lzoload -r -v -h 172.21.73.101 -b 0x100000 jffs2fs.imgfis write -b 0x100000 -f 0x7F260000 -l 0x250000fis create -f 0x7F260000 -l 0x590000 jffs2.imgreset问题描述:第一次启动,会出现CRC错误信息,如下:Shell invoked to run file: /etc/rcWelcome to____ _ _/ __| ||_|_ _| | | | _ ____ _ _ _ _| | | | | | || | _ \| | | |\ \/ /| |_| | |__| || | | | | |_| |/ \| ___\____|_||_|_| |_|\____|\_/\_/| ||_| ADVANTECH eAutomationFor further information check://eAutomation/Execution Finished, ExitingSash command shell (version 1.1.1)/> JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06ddc8.{ff5c,ff5c,ff5cff5c,6cedd300}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06c8c4. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06b3c0. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0006d394: read 0xc96c7e1f, calculated 0xc6974f8f.JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0006be3c: read 0xfaffca56, calculated 0x4e72e8e5.JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x071460. {ff1c,ff1c,ff1cff1c,ff1cff1c}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x0709ac: read 0x8db9f359, calculated 0x22676b8JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06fea4. {ff1c,ff1c,ff1cff1c,ff1cff1c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x06f3b4. {1985,e002,0000df5e,a5032844}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x06e91c: read 0x603ebf95, calculated 0x28f62bdbJFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x00071d6c: read 0xe3e40d9c, calculated 0x3b79fefa.JFFS2 warning: (164) jffs2_do_read_inode_internal: Truncating ino #29 to 23732 bytes failed because it only had 12288 bytes to start with!JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x0007c694: read 0xe9808a11, calculated 0x98c8ae6e.JFFS2 notice: (164) check_node_data: wrong data CRC in data node at 0x00076ba0: read 0x8207a914, calculated 0xa68949a.0x090240. {ff5c,ff5c,ff5cff5c,ff5cff5c}JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08dc84. {ff1c,ff1c,ff1cff1c,ff1cff1c}Node totlen on flash (0xdf1edf1e) != totlen from node ref (0x000009d8)JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08d1e8. {1985,e002,ff5cff5c,415e1f8f}JFFS2 notice: (164) read_dnode: node CRC failed on dnode at 0x08c7b4: read 0x62c24375, calculated 0x4b07ea0JFFS2 notice: (164) jffs2_get_inode_nodes: Node header CRC failed at 0x08b19c./>重启,则不会有如上CRC错误信息。
问题原因:我在烧写jffs2 img之前,使用fis init -f 来擦除flash。
fis init -f 命令执行完以后,flash空间就都是0xFF了!即使在mkfs.jffs2的时候使用'-p'参数指定最终输出img的大小,但是超出文件系统的部分也会被填充为0xFF!但这可不是jffs2的格式!我用fis create分了5M多(0x590000)的分区,但是jffs2fs.img只有不到3M(0x250000),那么把它烧写到flash以后,分区中除了jffs2 img之外剩余的flash空间(大概2M)全是0xFF,这不是jffs2要求的格式,所以,会发出CRC错误的信息。
假如有一种工具,他可以将flash format为jffs2的格式,那么就不会出现这个问题了。
目前我还没有找到这种工具,但是,可以确信的是:上面的CRC错误是不影响jffs2文件系统的使用的!The kernel is uClinux-dist.R1.1-RC3.The Memory chip is an 8MB M25P64 device.I created the jffs2 image originally using: mkfs.jffs2 -p 0x400000 -e 0x400000 -d jffsdir -o jffs2.img This was done on the target device.I think i may have found one possible issue looking again at my configuration..I have the bootloader in the first 1mb, the jffs2 in 1-5 (4 mb) and the kernel is at 5-8 (3 mb). However, on that basis my partition data below is incorrect.static struct mtd_partition bfin_spi_flash_partitions[] = {{.name = "bootloader",.size = 0x20000,.offset = 0,.mask_flags = MTD_CAP_ROM},{.name = "file system",.size = 0x400000,.offset = 0x100000,},{.name = "kernel",.size = 0x300000,.offset = 0x400000}};I think Kernel should be offset 0x500000 nor 0x400000, so i will make this change now.Another question, what does the MTD_CAP_ROM flag do? Does it make it Read only? If so, should I have this flag on the Kernel as well?yes, MTD_CAP_ROM makes things read-only. that way you can flag the bootloader as read-only and not worry about userspace accidentally erasing/corrupting it.some people like to update the kernel from userspace rather than the boot loader ... so that should dictate whether you set MTD_CAP_ROM on the kernel partitionThis error is thrown only the _first_ _time_ I erase the flash partition and flash the image to the partition. From next time booting (without re-flashing the image) this error is not shown by the Kernel. Each time I relash the partition with the _same_ _JFFS2_ image to the same location in flash the locations shown in CRC error keeps changing.I tried '-p' option in the mkfs.jffs2 utility this error is not coming.-p, --pad[=SIZE] Pad output to SIZE bytes with 0xFF. If SIZE is not specified, the output is padded to the end ofthe final erase blockCould anyone let me know why its giving the earler CRC error.。