如何正确地使用oob替换nanddump的转储? [英] How to correctly nandwrite a nanddump'ed dump with oob?

查看:238
本文介绍了如何正确地使用oob替换nanddump的转储?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在努力在Linux中闪存嵌入式设备的以前的ROM转储。我以前的转储包含oob数据。我用 nandwrite -n -N -o / dev / mtd0 backup.bin 写了它,然后再次取出一个ROM转储。



通过比较旧的和新的ROM转储,我看到一些不可解释的情况:任何空块(填充0xFF)的oob(ecc字节)的最后24个字节也应该是0xFF,但是新ROM转储中的那些填充0x00,导致后来的写入失败。



oob应该是:

  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
/ pre>

但对于 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; i if(((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转储的问题。



更多信息可以在我的博文



修补程序发送到linux -mtd列表实际上提到了事实


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 is 0xFF, 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 with 0xFF. But for pages with only 0xFF the ecc bytes are still polluted by 0x00 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 of 0xFF), the program will skip writing it (as a flash_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 gets 0x00. This is strange, because I should have already disabled ECC in the arguments of nandwrite. 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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆