From: Schrempf Frieder > Sent: 17 February 2020 11:19 > > Schrempf Frieder <frieder.schrempf@xxxxxxxxxx> wrote on Tue, 11 Feb > > 2020 16:35:53 +0000: > > > >> From: Frieder Schrempf <frieder.schrempf@xxxxxxxxxx> > >> > >> Currently when marking a block, we use spinand_erase_op() to erase > >> the block before writing the marker to the OOB area without waiting > >> for the operation to succeed. This can lead to the marking failing > >> silently and no bad block marker being written to the flash. > >> > >> To fix this we reuse the spinand_erase() function, that already does > >> everything we need to do before actually writing the marker. > >> > > > > Thanks a lot for this series! > > > > Yet I don't really understand the point of waiting for the erasure if > > it failed: we don't really care as programming (1 -> 0) cells is always > > possible. Are you sure this lead to an error? > > We don't care about the result of the erase operation, but I think we > still need to wait for it to be done and the STATUS_BUSY bit to be > cleared. Otherwise it seems like the program operation to set the marker > can get ignored by the chip. At least that's my explanation for the > behavior I was observing. Serial flash devices won't allow any accesses while an erase or write in in progress. So while you don't need to wait for either to finish, you do need to remember that one is 'pending' and wait for it to finish before any further accesses (apart from reads of the status register). How many writes you can do to an area (that clear 1s) and the size of the area will be device dependant. IIRC one device I've used allows 2 writes to each 16bit word. This allows either two separate byte writes or one write of a 16bit (or 32bit) value followed by a second write of all 0s the 'erase' the value without doing a erase-rewrite cycle. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
