> > Hey Avri, > > >> Yeah I have indeed only seen ERASE_SEQ_ERROR, but added the rest > >> because it doesn't hurt. > > ERASE_SEQ_ERROR - It is set when e.g. CMD36 is given before CMD35 e.g. > the following CMDs are issued CMD36 -> CMD35 -> CMD38 In the response > of CMD36, ERASE_SEQ_ERROR error bit will be reported. > > This can't be happening for mmc-utils because it send the correct sequence > using multi-ioctl - Which assure it can't be interrupted by any other > command. > > The trace that you attached looks like a fw bug to me. > > I disagree, requoting the eMMC spec I quoted originally, considering an OOR > erase address: > 'If the host provides an out of range address as an argument to CMD35 or > CMD36, the Device will reject the command, respond with the > ADDRESS_OUT_OF_RANGE bit set and reset the whole erase sequence." > So CMD38 must trigger ERASE_SEQ_ERROR for OOR on MMC and it is a (HW) > bug if it doesn't. It makes sense but let me confirm first and get back to you on that. > > > > >> Why would you say ERASE_PARAM shouldn't be checked? Or are you > arguing > >> it should only be checked at CMD38 (i.e. the X of CMD35)? > > ERASE_PARAM - It is set when wrong address is given for first erase group > in CMD35, And is reported in the response of CMD36. > > This is actually the only error bit we should look for. > > > >> (In which case I agree, just didn't want more than one error mask) > >> Seeing a ERASE_PARAM would definitely make the erase not happen > >> (that's all mmc-utils should really care about). > >> ERASE_RESET may be removed for sure, could be checked when a SD ioctl > >> erase fix like I described is in the kernel. > > ERASE_RESET is set when any other commands apart from > CMD35/36/38/13 is sent during the erase sequence. > > This as aforesaid, can't be happening for mmc-utils. > > I disagree here, too. > Just because we are not sending it doesn't mean the card does not see it. > The card may sample a CMD start bit at some time during the sequence, will > not answer because of ILLEGAL / CRC mismatch. > The sequence is reset anyway (out of sequence command received). This is > not unthinkable on neither SD nor MMC bus. Vanishingly remotely as there are no cmd nor data error, but ok. > ERASE_SEQ_ERROR at CMD38 will catch that, too, though. > > > > >> Then an ideal mmc-utils erase operation checks that no relevant R1 > >> bits are set at CMD38 RSP and all CMD13 until card leaves PRG and > >> stops signalling busy. > > Are you suggesting that we should include cmd13 as the 4th command in > the erase sequence? > > I am not sure we need it. > > I am. > At any point there is some operation making changes to the flash, be it > writes or erases, the busy will be asserted (assuming cache off). > When busy is deasserted host needs to check why this was the case. > Consider a flash voltage drop, card may signal e.g. the general error bits, but > behavior depends on the card of course. > If issuing a secure erase, I would like to know if busy of CMD38 was > deasserted because of successful completion or some other error and erase > was in fact not fully executed. > mmc-utils cannot fix this on its own, so for now let's restrict this patch to > OOR erases and so on for MMC-only. OK. Please try to reuse the send-status code we already have. > > > To conclude, IMO only ERASE_PARAM should be checked in the response > of CMD36. > I think ERASE_PARAM should be checked for CMD36, ERASE_SEQ_ERROR for > CMD38, I'm fine with removing ERASE_RESET check for the patch, it is caught > at CMD38 ERASE_SEQ_ERROR anyway. > What do you say? Please let me confirm first about ERASE_SEQ_ERROR in cmd38. Thanks, Avri > > Regards, > Christian > > Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz > Managing Director: Dr. Jan Peter Berns. > Commercial register of local courts: Freiburg HRB381782
