duplicate DoC millenium with dd
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
>> 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
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
this is kinda bad news.......
More information about the linux-mtd