|
首先我们来了解一下UFS与eMMC eMMC eMMC (EmbeddedMulti Media Card) 为MMC协会所订立的、主要是针对手机或平板电脑等产品的内嵌式存储器标准规格。eMMC目前是最当红的便携移动产品解决方案，目的在于简化终端产品存储器的设计。由于NAND Flash芯片的不同厂牌包括三星、东芝或海力士、镁光等，当设计厂商在导入时，都需要根据每家公司的产品和技术特性来重新设计，过去并没有1个技术能够通用所有厂牌的NAND Flash芯片。 eMMC的设计概念，就是为了简化内存储器的使用，将NAND Flash芯片和控制芯片设计成1颗MCP芯片，手机客户只需要采购eMMC芯片，放进新手机中，不需处理其它繁复的NAND Flash兼容性和管理问题，最大优点是缩短新产品的上市周期和研发成本，加速产品的推陈出新速度。 现在，eMMC 4.5已经问世，eMMC 4.4的读取速度大约为104MB/s、eMMC 4.5则为200MB/s，性能在当时也是十分优秀的；而在2013年7月29日三星开始量产行业首款eMMC 5.0存储产品，其读取速度为400MB/s，但是因为使用的是8位并行界面，因此性能潜力已经基本到达瓶颈，以最新的eMMC 5.1规范来说，其理论带宽为600MB/s左右，性能的大提升基本是不可能的了。 UFS 2011年电子设备工程联合委员会（Joint Electron Device En gineering Council，简称JEDEC）发布了第一代通用闪存存储（Universal Flash Storage，简称UFS）标准，希望能够替代eMMC。然而，第一代的UFS并不受欢迎，因为相对于不断更新换代的eMMC它似乎没有提供足够的优势。为此，JEDEC在2013年9月发布了新一代的通用闪存存储标准UFS 2.0，该标准下的闪存读写速度可以高达每秒1 400MB，这相当于在两秒钟内读写两个CD光盘的数据，不仅相比eMMC它有巨大的优势，它甚至能够让电脑上使用的闪存存储介质固态硬盘也相形见绌。 UFS 2.0的闪存使用的是串行界面，很像PATA、SATA的转换。并且它支持全双工运行，可同时读写操作，还支持指令队列。相比之下，eMMC是半双工，读写必须分开执行，指令也是打包的，在速度上就已经是略逊一筹了。而且UFS芯片不仅传输速度快，功耗也要比eMMC 5.0低一半，可以说是旗舰手机闪存的理想搭配。 除了在速度性能方面有着巨大优势之外，在功耗方面UFS 2.0也有更好表现。事实上，如果从功耗方面来比较，即使是新一代的UFS 2.0标准也是能够与eMMC持平。不过eMMC和UFS 2.0在操作过程中消耗的功率约为1mW(毫瓦)，而待机状态下功耗将低于0.5mW。当UFS 2.0满载时，所消耗的功率实际上比eMMC还要多，但它可以更快地完成操作而更早地切换到待机状态，因此在功耗方面的表现UFS 2.0与eMMC不相上下。（from MIUI论坛） 那有如何来判断手机到底是UFS还是eMMC呢？ 首先我们需要用到一个小工具“终端模拟器”（私信回复'终端模拟'即可获得下载地址） 基础篇：UFS还是eMMC？ 工具：“Terminal Emulator for Android”等 终端模拟器 条件：不用ROOT，无需超级用户（“$”） 代码：ls /proc/fs/*（ls后有半角空格） 结果：返回结果中“/proc/fs/f2fs:”后为“mmcblk”开头，闪存接口为eMMC；“/proc/fs/f2fs:”后为“sd”开头，则闪存接口为UFS。 进阶篇：UFS闪存的具体型号？ 工具：“Terminal Emulator for Android”等 终端模拟器 条件：不用ROOT，无需超级用户（“$”） 代码：cat /proc/scsi/scsi（cat后有半角空格） 结果：返回结果中“Vendor:”后为闪存厂商，“Model:”后为闪存具体型号。 终极篇：到底是UFS2.0还是UFS2.1？? 工具：终端模拟器 条件：需要ROOT，需要超级用户（“#”） 代码：cat /sys/kernel/debug/ufs/dump_device_desc （cat后有半角空格） 结果：返回结果中“Device Deor[Byte offset 0x10]: wSpecVersion = 0x2”则为UFS2.0，“Device Deor[Byte offset 0x10]: wSpecVersion = 0x21”则为UFS2.1。此方法通过直接读取闪存标志位，不用查询具体型号，即可获得闪存类型。 例如，对于闪存KLUCG4J1EB-B0B1（三星UFS2.0），结果为： Device Deor[Byte offset 0x0]: bLength = 0x40 Device Deor[Byte offset 0x1]: bDeorType = 0x0 Device Deor[Byte offset 0x2]: bDevice = 0x0 Device Deor[Byte offset 0x3]: bDeviceClass = 0x0 Device Deor[Byte offset 0x4]: bDeviceSubClass = 0x0 Device Deor[Byte offset 0x5]: bProtocol = 0x0 Device Deor[Byte offset 0x6]: bNumberLU = 0x4 Device Deor[Byte offset 0x7]: bNumberWLU = 0x4 Device Deor[Byte offset 0x8]: bBootEnable = 0x1 Device Deor[Byte offset 0x9]: bDescrAccessEn = 0x0 Device Deor[Byte offset 0xa]: bInitPowerMode = 0x1 Device Deor[Byte offset 0xb]: bHighPriorityLUN = 0x7f Device Deor[Byte offset 0xc]: bSecureRemovalType = 0x0 Device Deor[Byte offset 0xd]: bSecurityLU = 0x1 Device Deor[Byte offset 0xe]: Reserved = 0x4 Device Deor[Byte offset 0xf]: bInitActiveICCLevel = 0x0 Device Deor[Byte offset 0x10]: wSpecVersion = 0x2 Device Deor[Byte offset 0x12]: wManufactureDate = 0x1610 Device Deor[Byte offset 0x14]: iManufactureName = 0x0 Device Deor[Byte offset 0x15]: iProductName = 0x1 Device Deor[Byte offset 0x16]: iSerialNumber = 0x2 Device Deor[Byte offset 0x17]: iOemID = 0x3 Device Deor[Byte offset 0x18]: wManufactureID = 0xce01 Device Deor[Byte offset 0x1a]: bUD0BaseOffset = 0x10 Device Deor[Byte offset 0x1b]: bUDConfigPLength = 0x10 Device Deor[Byte offset 0x1c]: bDeviceRTTCap = 0x2 |
|
|
