>> I prefer to not erase the block before writing the bad block marker. The >> rationale is that bad blocks might have various problems and the fewest  >> possible writes should be performed on the block. Erasing the block might  >> cause problems with marking the block. I'm of bit different opinion here. In case if you want to have same driver working for MLC and SLC nand flashes, then ideally you need to erase the block before writing anything on to it  (including bad block marker).  As MLCs do not allow multiple write operations on to the same page without erasing, you may lose the marker data itself in  cases of marking without erase operation. Thanks, Venu ________________________________ From: Charles Manning To: venu Sent: Friday, 16 December 2011 1:31 AM Subject: Re: [Yaffs] about retiring a block No that is not so. Bad block markers should be structured in a way that they can be marked without an erase. If the driver has some strange bad block marking strategy that requires erasure then it is up to the driver to perform the erasure as part of the bad block marking. Most Linux drivers reserve the first 2 oob bytes as a bad block marker and all that is needed is to write these to zero. I prefer to not erase the block before writing the bad block marker. The rationale is that bad blocks might have various problems and the fewest possible writes should be performed on the block. Erasing the block might cause problems with marking the block. On Thursday 15 December 2011 19:26:09 venu wrote: > Ideally erase operation should happen before marking block as BAD. > Without that we cannot ensure that the block will be really marked BAD. > > > ________________________________ >  From: zheng shi > To: YAFFS > Cc: Charles Manning > Sent: Thursday, 15 December 2011 11:38 AM > Subject: [Yaffs] about retiring a block > > Hi, > I found it strange that there's no block erase operation before > calling yaffs_mark_bad. > But in mtd_utils/nandwrite.c, the block is erased before marking bad. > > Is it the expected behavior? > > Thanks!