On Monday, September 12, 2011 08:31:12 PM Scott Wood wrote:
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?
No! What if (very possible situation actually) the user wants to use the whole NAND because the user is booting from SD/SPI/... ?
I'm curious why anything is written on an erase, though, regardless of data format.
Badblock markers (some FSL invention) are written always.
-Scott