duplicate DoC millenium with dd
Nikolai Vladychevski
niko at isl.net.mx
Tue Sep 11 18:20:37 EDT 2001
David Woodhouse writes:
>
> niko at isl.net.mx said:
>> yes, this is the problem... right now I'm leaving 1 Meg for the
>> linuxBIOS and kernel and right now there is left as little as 40 K
>> bytes free space of that meg.
>
> Use modules?
yes, I do, but it still big, its a 2.4.7
>
>
>> If I update the software on the chip once a week (it's an automatic
>> update via remote server), will it survive for 2 years without
>> errors, for example ?
>
> It doesn't degrade over time. Using it the first time may lose the
> bad-block information which is put on it by the NAND flash chip
> manufacturer (Toshiba or Samsung, not M-Systems). After that there's no
> difference.
>
>> Wow! that sounds cool! I have to try it, but would linuxBIOS conflict
>> with it?
>
> No, should be fine. You could have it appear as three MTD devices - one for
> LinuxBIOS, one for the kernel, and one for cramfs.
I'm sorry, I can't find any docs about creating partitions, mtd0, mtd1,
mtd2, etc..? list archives dont help either, how it is done?
>
> Using cramfs directly on the NAND flash gives you no error correction and
but wait a minute, if I enable these options:
<*> NAND Device support
[*] Enable ECC correction algorithm
[*] Verify NAND page writes
won't it help me?
> no facility to work around bad blocks. I wouldn't wan to do it like that in
> production, although in practice it'll work unless you have a chip with bad
> blocks.
well, my environment will be production,so I guess I'm out of luck because
if I take your precautions:
1) I can't use nftl_format
2) I can't use mtd partitioning because I will write directly on the NAND
flash.....
this is kinda bad news.......
nikolai
More information about the linux-mtd
mailing list