控制台查看emmc寿命（eMMC深入浅出第四章）

CMD0 is always the first command we see, just like the engine start button. As we mentioned in the previous Boot and Reset topics, there are 3 kinds of argument for CMD0. CMD0 with argument 0xF0F0F0F0 is software reset to change eMMC device State machine to Pre-Idle State in the Boot Mode, CMD0 with argument 0x00000000 is another light software reset to Idle State in Card Identification Mode. While CMD0 with argument 0xFFFFFFFA is the alternate boot operation to change eMMC device state machine into Boot State in Boot Mode.，下面我们就来说一说关于控制台查看emmc寿命?我们一起去了解并探讨一下这个问题吧!

控制台查看emmc寿命

CMD0 is always the first command we see, just like the engine start button. As we mentioned in the previous Boot and Reset topics, there are 3 kinds of argument for CMD0. CMD0 with argument 0xF0F0F0F0 is software reset to change eMMC device State machine to Pre-Idle State in the Boot Mode, CMD0 with argument 0x00000000 is another light software reset to Idle State in Card Identification Mode. While CMD0 with argument 0xFFFFFFFA is the alternate boot operation to change eMMC device state machine into Boot State in Boot Mode.

CMD0总是我们看到的第一个指令，就像是引擎启动按钮。我们前面在启动和复位话题中提到过，一共有三种参数的CMD0。CMD0带参数0xF0F0F0F0是软件复位把eMMC状态机置位到启动模式的预闲置状态，CMD0带参数0x00000000是另一种轻量级的软件复位把eMMC置位到卡识别模式的闲置状态。而CMD0带参数0xFFFFFFFA是可替换的启动操作把eMMC器件的状态机置位到启动模式下的启动状态。

CMD0 is a quite different command from others, it is the only one out of three commands which do not need response from eMMC device. Why no need response? There might be several reasons I could think of for discussion. The reason one is that when eMMC receive the first at that very beginning moment, there is no need to report eMMC device status as all the three kinds of CMD0 are with specific functions. The second reason is that the very beginning moment is the hand shaking phase between Host and eMMC device, Host might not expect to receive anything as the result of hand shaking failure.

CMD0是一个和其他指令非常不同的指令，这是仅有的三个不需要eMMC器件应答的指令之一。为什么不需要应答？或许有几个我能想到的可以拿来讨论的原因，第一个原因是当eMMC器件在一开始收到这第一个指令的时候，没必要做应答因为这所有三种CMD0都完成非常特定的功能。第二个原因是在那个一开始的时刻是主机和eMMC器件的握手阶段，主机可能因为握手失败而并不一定指望能得到应答。

But the deeper reason might be because of the eMMC response mechanisms. Based on the eMMC specification, eMMC response is right after the Host command, there is no problem for those commands without data transferring, while for the commands followed by data transferring like read/write, this response cannot cover the whole data transfer status since it is prior of the data sector transmitting. From this point of view, it is better for the current response to reflect the last command execution result. CMD0 has no command prior to it, no need for the response then, only need to wait for the next command response. In UFS specification, the response UPIU (UFS Protocol Information Unit, we will not go into detail here, will cover it in the UFS topics) is always after the data In/Out UPIU.

但是更深层次的原因可能是因为eMMC的应答机制。根据eMMC的规范，eMMC的应答是紧跟着主机指令的，这个对于没有数据传输的指令是没问题的，但是对于那些跟着数据传输的指令比如读写，这种应答没办法涵盖数据传输的状态因为他在数据传输之前。从这个观点来看，最好是当前的应答反映上一个指令执行的结果。CMD0之前没有指令，所以没有必要应答，只需要等待下个指令的应答。在UFS规范里，应答UPIU（UFS协议信息单元，我们在这不深入细节，会在以后的UFS话题中聊）总是在数据进/出的UPIU之后。

The other commands with no response are CMD4 and CMD15. CMD4 is to set DSR （Driver Strength Register）while CMD15 is to put device in the Inactive State. CMD15 is redundant reset command and hardly be used. We have ever mentioned it in the Reset topic.

另两个不需要应答的指令是CMD4和CMD15。CMD4设置DSR寄存器（驱动强度寄存器，而CMD15把eMMC置位到不活跃状态。CMD15是个冗余的复位指令几乎没用。我们曾经在复位话题中聊到过。