2009-06-26 05:43:36     ¿spurious? corruption in some flash pages

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

2009-06-26 05:43:36     ¿spurious? corruption in some flash pages

Juan A. Quintero (SPAIN)

Message: 76378   


Hi all, I'm new here.


First of all, it's nice to have a forum where you get answers to your headaches. Thanks to you all, you helped me many times, in spite of I've never ask for anything here (until today).


I'm having some strange behaviour after flashing some data and dindn't find a similar topic, so I have to beg for help. I have to flash a file system to a mtd partition, and sometimes, it doesn't work properly if the flash had previously dummy data or rubbish.


I'm flashing an image (kernel + file system) to the particion thar uboot uses for boot, but sometimes I have a bad crc error when uboot tries to run it. Then, I use a tftpboot command to load a remote partition to be able to get the flash, but when I get the flash data is exactly the same as a working one. When you boot again from flash, the image is loaded surprisingly with no crc error.


The sequence is:


-flash_eraseall /dev/mtd2


-cat myfilesystem > /dev/mtd2




-Got the crc error, so run a remote image loaded by tftp


-cat /dev/mtd2 > /tmp/flash_dump (/tmp is obviously in RAM)


-md5sum /tmp/flash_dump answers a number equals to myfilesystem


-Boot again from flash


-All ok, the crc check is ok and linux boots as usual. (weird, we just read from flash, nobody wrote!!)




I recompiled uboot so that we don't check the crc of the image loaded, and that's what I got:


EXT2-fs error (device mtdblock0): ext2_check_page: bad entry in directory #216: rec_len is smaller than minimal - offset=0, inode=0, rec_len0

Warning: unable to open an initial console.


And of course, a kernel panic.


Any idea or suggestion?


I cannot update the uclinux rc(R1.1 RC3) or the uboot (1.1.6 analog) so I have to patch them




Thanks in advance




2009-06-26 06:01:34     Re: ¿spurious? corruption in some flash pages

Juan A. Quintero (SPAIN)

Message: 76380   


Forgot to say I'm using a 25p64 flash type, but I dindn't find a related bug dealing with this flashes.




2009-06-27 12:42:58     Re: ¿spurious? corruption in some flash pages

Mike Frysinger (UNITED STATES)

Message: 76430   


uhh, you cant use ext2 on a flash device.  you must use a flash filesystem.  for SPI flash, that means jffs.




2009-06-29 06:15:15     Re: ¿spurious? corruption in some flash pages

Juan A. Quintero (SPAIN)

Message: 76459   


It's a read-only ball that i decompress over ram, so there's no point in using jffs.




2009-06-29 12:35:18     Re: ¿spurious? corruption in some flash pages

Mike Frysinger (UNITED STATES)

Message: 76477   


that isnt what your output suggests ... looks to me like your directly mounting the device


we've never tested non-flash filesystems on flash devices.  it may work, it may not, it's a bad idea either way.




2009-06-30 08:58:59     Re: ¿spurious? corruption in some flash pages

Juan A. Quintero (SPAIN)

Message: 76525   


I didn explain it well. The image is mounted directly but it is a read only mounting. That's the reason why we didn't need any flash file system. Historically, it was a cramfs, a ramdisk that was copied to ram (uboot did it) and kernel was summoned with "root=/dev/ram0 rw"


I don't know why someone decided here to change it but the problem seems to be in the uboot, because the kernel is summoning via "root=/dev/mtdblock0 rw" and the "w" was screwing me.


Anyhow, I don't agree with using jffs or any other flash-oriented file system in systems where the data is read only forever. It was very common before jffs was a trustable file system to tar a cramfs o ext2 and flash it, and in runtime, copy to ram and mount it. (it is the recommended way to do it by several development board companies).


Thanks anyway for answering. It is not easy to get any answer in topics like this. And please excuse my english!