如何正确地使用oob替换nanddump的转储? [英] How to correctly nandwrite a nanddump'ed dump with oob?
问题描述
nandwrite -n -N -o / dev / mtd0 backup.bin
写了它,然后再次取出一个ROM转储。 通过比较旧的和新的ROM转储,我看到一些不可解释的情况:任何空块(填充0xFF)的oob(ecc字节)的最后24个字节也应该是0xFF,但是新ROM转储中的那些填充0x00,导致后来的写入失败。
oob应该是:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
/ pre>
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
但对于
nandwrite
:FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF 00000000 00000000
00000000 00000000 00000000 00000000
任何人都知道为什么?
我添加了在
nandwrite
代码中,如果要写入的内容是0xFF
,则可以跳过写入NAND,并且它的工作。那么当尝试向NAND写一个空页时,存在问题?
ADDED:
现在我在编写引导加载程序镜像时也遇到了这个问题。图像不是页面对齐的,所以
nandwrite
用0xFF
填充它。但是对于只有0xFF
的页面,ecc字节仍然像上面一样被0x00
污染。似乎我的黑客并不能完全解决我的问题。任何人都可以帮忙也许这可能是内核2.6.35中的错误?
这是我的黑客:
int i;
int needwrite = 0; (i = 0; iif(((uint8_t *)data)[i]!= 0xff){
needwrite = 1;
break;
}
}
if(!needwrite)
return 0;
解决方案我的 hack 正在添加检查
nandwrite
,如果要写入的整个页面是完全空的(即,充满0xFF
),程序将跳过写入(作为flash_erase
已经完成)。
额外的优点是:
nandwrite
的整个过程更快,因为跳过空白页面。 Horray!
ADDED:
原来我的黑客没有真正解决问题...
再次添加: (实际解决方案)
事实上,问题是PXA310用
0x00填充硬件ECC位
为空白页面,所以如果软件写一个空页面,这些位将获得0x00
。这是奇怪的,因为我应该已经禁用了$ code> nandwrite 的参数中的ECC。幸运的是,跳过写空白的页面可以防止重写ROM转储的问题。
更多信息可以在我的博文。
I am struggling on flashing a previous ROM dump of an embedded device in Linux. My previous dump contains oob data. I wrote it with
nandwrite -n -N -o /dev/mtd0 backup.bin
, and then take a ROM dump again.By comparing the old and new ROM dump, I see some un-explainable situation: the last 24 bytes of the oob (ecc bytes) of any empty blocks (filled with 0xFF) is ought to be 0xFF also, but those in the new ROM dump is filled with 0x00, causing later write failures.
oob ought to be:
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
but for
nandwrite
:FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 00000000 00000000 00000000 00000000 00000000
Anyone has any idea why?
I added a hack in the
nandwrite
code, to skip writing to NAND if the content to be written is0xFF
, and it worked. So the problem exists when trying to write an empty page to the NAND?
ADDED:
Now I am having this problem also when writing a bootloader image. The image isn't page-aligned so
nandwrite
padded it with0xFF
. But for pages with only0xFF
the ecc bytes are still polluted by0x00
just like above. Seems that my hack doesn't totally solve my problem. Anyone can help? Perhaps it could be a bug in kernel 2.6.35?This is my hack:
int i; int needwrite=0; for (i = 0 ; i < len ; ++i){ if(((uint8_t*)data)[i]!=0xff){ needwrite=1; break; } } if(!needwrite) return 0;
解决方案My hack is adding a check in
nandwrite
, that if the whole page going to be written is totally empty (i.e. full of0xFF
), the program will skip writing it (as aflash_erase
had been done).An extra benefit is that the whole process of
nandwrite
got faster because of skipping empty pages. Horray!
ADDED:
It turned out that my hack didn't actually solve the problem...
ADDED again: (real solution)
The problem is in fact the PXA310 fills the hardware ECC bits with
0x00
for a blank page, so if the software writes an empty page, the bits gets0x00
. This is strange, because I should have already disabled ECC in the arguments ofnandwrite
. Luckily skipping writing empty pages works in preventing problems with re-writing a ROM dump.More information can be found in my blog post.
A patch sent to the linux-mtd list actually mentioned about the fact.
这篇关于如何正确地使用oob替换nanddump的转储?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!