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. > >> 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. 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. > 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? Regards, Christian Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782
