> > 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? OK - Lets continue with our current understandings. Btw, you might want to consider support for SD as well (in a different commit) - SD doesn't support cmd35 & cmd36, but cmd32 & cmd33 instead, and its response nuances are defined in the SD spec. Thanks, Avri > 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
