svn commit: r50185 - head/en_US.ISO8859-1/htdocs/news/status

Thu Apr 20 04:06:35 UTC 2017

Author: bjk
Date: Thu Apr 20 04:06:34 2017
New Revision: 50185
URL: https://svnweb.freebsd.org/changeset/doc/50185

Log:
  Add 2017Q1 entry on eMMC and SD card improvements from marius

Modified:
  head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml

Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml
==============================================================================

--- head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml	Thu Apr 20 03:40:07 2017	(r50184)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2017-01-2017-03.xml	Thu Apr 20 04:06:34 2017	(r50185)
@@ -954,4 +954,95 @@
       <task>Submit the remaining fixes and drivers.</task>
     </help>
   </project>
+
+  <project cat='proj'>
+    <title>Support for eMMC flash and Faster SD Card Modes</title>
+
+    <contact>
+      <person>
+	<name>
+	  <given>Marius</given>
+	  <common>Strobl</common>
+	</name>
+	<email>marius at FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>In r315430, support for eMMC partitions has been added to
+	<tt>mmc(4)</tt> and <tt>mmcsd(4)</tt> in &os; 12.  Besides the
+	user data area, i.e., the default partition, eMMC v4.41 and
+	later devices can additionally provide up to:</p>
+
+      <ul>
+	<li>1 enhanced user data area partition</li>
+
+	<li>2 boot partitions</li>
+
+	<li>1 RPMB (Replay Protected Memory Block) partition</li>
+
+	<li>4 general purpose partitions (optionally with a enhanced
+	  or extended attribute)</li>
+      </ul>
+
+      <p>Apart from simply subdividing eMMC flash devices or having
+	UEFI code in the boot partition, as is done on some Intel NUCs,
+	another use case for partition support is the activation of
+	pseudo-SLC mode, which manufacturers of eMMC chips typically
+	associate with the enhanced user data area and/or the enhanced
+	attribute of general purpose partitions.</p>
+
+      <p>In order to be able to partition eMMC devices, r315430 also
+	added a Linux-compatible IOCTL interface to <tt>mmcsd(4)</tt>.
+	This allows for using the GNU <tt>mmc-utils</tt> (found in ports
+	as <tt>sysutils/mmc-utils</tt>) on &os;.  Besides partitioning
+	eMMC devices, the <tt>mmc</tt> tool can also be used to query
+	for life time estimate and pre-EOL information of eMMC flash, as
+	well as to query some basic information from SD cards.</p>
+
+      <p>CAVEAT EMPTOR: Partitioning eMMC devices is a one-time
+	operation.</p>
+
+      <p>Additionally, in order to make eMMC flash devices more
+	usable, support for DDR (Dual Data Rate) bus speed mode at a
+	maximum of 52 MHz (DDR52) has been added to <tt>mmc(4)</tt>
+	and <tt>sdhci(4)</tt> in r315598, i.e., in &os; 12.  Compared
+	to high speed mode (the previous maximum) at 52 MHz, DDR52
+	mode increases the performance of the tested eMMC chips from
+	~45 MB/s to ~80 MB/s.</p>
+
+      <p>So far, support for DDR52 mode has been enabled for the eMMC
+	controllers found in Intel Apollo Lake, Bay Trail and Braswell
+	chipsets.  Note, however, that the eMMC and SDHCI controllers
+	of the Apollo Lake variant occasionally lock up due to a
+	silicon bug (which is independent of running in DDR52 mode).
+	The only viable workaround for that problem appears to be the
+	implementation of support for ADMA2 mode in <tt>sdhci(4)</tt>
+	(currently, <tt>sdhci(4)</tt> supports the encumbered SDMA
+	mode only, or no DMA at all).</p>
+
+      <p>However, r315598 also already brought in infrastructure and
+	a fair amount of code for using even faster transfer modes with eMMC
+	devices and SD cards respectively, i.e., up to HS400ES with eMMC
+	and the UHS-I modes up to SDR104 with SD cards.</p>
+
+      <p>The intent is to merge these changes back to &os; 10 and 11.</p>
+    </body>
+
+    <help>
+      <task>Add support for eMMC HS200, HS400 and HS400ES transfer
+	modes.</task>
+
+      <task>Add support for SD card UHS-I transfer modes (SDR12 to
+	SDR104).</task>
+
+      <task>Make <tt>mmcsd(4)</tt> more robust and correctly follow
+	the relevant specifications for existing features, e.g.,
+	calculate and handle erase timeouts, do a <tt>SEND_STATUS</tt>
+	when CMD6 is invoked with an R1B response to the extent not
+	already fixed as part of r315430, get the remainder of the
+	existing code to properly check and handle return codes,
+	etc.</task>
+    </help>
+  </project>
 </report>
