[U-Boot] [PATCH 5/5] NAND: Add scrub.quiet command option

[Scott Wood]

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