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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
