[PATCH 6/6] [MTD-UTILS] nandwrite: Add Support for Reading from Standard Input
Schlaegl Manfred jun.
manfred.schlaegl at gmx.at
Fri Nov 28 17:40:30 EST 2008
Am Donnerstag, den 20.11.2008, 23:50 +0100 schrieb Ladislav Michl:
> On Mon, Sep 08, 2008 at 09:36:52AM -0700, Grant Erickson wrote:
> > On 9/8/08 9:14 AM, Ladislav Michl wrote:
> > > - code uses lseek. Obviously, you cannot seek on pipe.
> > True enough. The patch avoids the lseek to determine input file size;
> > however, did not address the 'markbad' recovery lseek case.
> > Short-term proposal: like 'writeoob', disable 'markbad' support when reading
> > from standard input and condition the whole 'markbad' logic on not reading
> > from standard input.
> It is not about marking bad blocks. Nandwrite will end with unrecoverable
> error on first failed write and that is not acceptable in production
On our productive Systems(automatic system-update) we wrote own code
with special security options:
The Image is written whole, without marking blocks bad, also if
write-errors occure, the number of errors will counted and as result we
deliver a "failed", with the number of write errors. Based on the number
of errors, we're able to react in diffent ways. For example:
* to many bad-blocks: heavy error -> abort, because of hardware error
* to many bad-blocks: image doesn't fit -> abort
* "block got bad" error -> rewrite with marking blocks bad (if new
errors occure -> repeat procedure)
But this is only reliable, if we there is an file-image.
So I think, one option is to do this by an command-line option:
"--makebad", or something. (see below)
> > > PS: It is remotely possible that one day I do it myself, but I'm
> > > notoriously slow on doing things I do not urgently need.
> Well, it took less than three months. Not so bad :-)
all day work sucks... *g*
> And it turned out to be imposible to fix it properly without solving
> following issue first.
> MEMSETOOBSEL ioctl used to implement these options
> -a, --autoplace Use auto oob layout
> -j, --jffs2 Force jffs2 oob layout (legacy support)
> -y, --yaffs Force yaffs oob layout (legacy support)
> -f, --forcelegacy Force legacy support on autoplacement-enabled mtd device
> -n, --noecc Write without ecc
> was removed more than two years ago and found its way into 2.6.18-rc1. See
> I hope legacy support can be safely removed (please raise your voice now)
> which leaves only --noecc for implementation. Possible scenarios are:
> 1. Image does not contain OOB data
> Read whole eraseblock to buffer and write it to flash
> 2. Image contains OOB data (--oob is given)
> Set MTDFILEMODE to MTD_MODE_RAW, read whole eraseblock
> (data:oob:data:oob...) into buffer and write it to flash
> 3. Image does not contain OOB data and --noecc is given
> Set MTDFILEMODE to MTD_MODE_RAW, read whole eraseblock,
> insert 0xff into OOB after each writeblock, write into
> 4. Image contains OOB data and --noecc is given
I think, the --noecc option only makes sense, if --oob ist not given.
The oob-option is, logically seen, more than a simply change in
handling, because we practically write to an abstract device.
> As I have never need writing images with OOB I'd like to ask for help
> how should be case 3 and 4 handled.
I used --oob for testing:
* to write a raw-image from physical(target) to nandsim(host) for
analysis (powerdown, etc.)
* generate bad-blocks on nand-devices for testing
--oob or --raw: writes unmodified data+oob (data:oob:data:oob, ...)
(raw-mode), if not given, write data, with autogenerated
* given: mark blocks with write errros as bad and perform write on
next block (caution: image-size)
* not given:
* write image at whole and count errors -> result
* or, abort on first error
The main issue I see, is the size of the device. Nobody is able to
predict the size of the destination device.
> Linux MTD discussion mailing list
More information about the linux-mtd