From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Mon, 12 Sep 2011 13:31:12 -0500 Subject: [U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option In-Reply-To: <201109122024.56858.marek.vasut@gmail.com> References: <1315800250-19761-1-git-send-email-marek.vasut@gmail.com> <201109121945.17407.marek.vasut@gmail.com> <4E6E4A23.1020101@freescale.com> <201109122024.56858.marek.vasut@gmail.com> Message-ID: <4E6E4FF0.10707@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/12/2011 01:24 PM, Marek Vasut wrote: > On Monday, September 12, 2011 08:06:27 PM Scott Wood wrote: >> On 09/12/2011 12:45 PM, Marek Vasut wrote: >>> On Monday, September 12, 2011 06:45:43 PM Mike Frysinger wrote: >>>> On Monday, September 12, 2011 00:04:10 Marek Vasut wrote: >>>>> This allows the scrub command to scrub without asking the user if he >>>>> really wants to scrub the area. Useful in scripts. >>>> >>>> "quiet" and "skip user input" are two different things. can you use a >>>> more clean option like accepting "-y" to the "scrub" subcommand ? >>> >>> I'd prefer to have this hidden from common users as much as possible. >> >> What's the use case for needing to script this, BTW? > > Update a block in NAND that's not handled by BCH accelerator in the MX28 chip. > > The problem is, block 0 has it's own ECC done by bootrom software. That kind of > ECC is incompatible with BCH-produced ECC. That's also a reason for needing that > write.raw command. > > Now, if you try erasing that block, the BCH reads and writes some of it's > metadata there. Obviously, since there is different kind of ECC, the metadata > aren't there and it chokes, claiming the block is bad and refuses to erase it. > > And before you ask why -- that's because the BCH accelerator puts the metadata > at random places in the block (every 512 bytes, it puts a few bytes of it's ECC) > instead of putting them only to the ECC area. On the other hand, the bootrom ECC > puts the whole ECC at offset (1024 + 12) bytes from the start of the block 0. Would it make sense to have the driver code treat block 0 specially (possibly conditioned on an hwconfig or compile-time config), rather than have it be user-driven? I'm curious why anything is written on an erase, though, regardless of data format. -Scott