[U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes

[Joakim Tjernlund]

Diego Santa Cruz <Diego.SantaCruz at spinetix.com> wrote on 2014/12/05 
09:38:34:
> 
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> > Sent: Thursday, December 04, 2014 7:29 PM
> > To: Diego Santa Cruz
> > Cc: u-boot at lists.denx.de
> > Subject: RE: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and 
related
> > fixes
> > 
> > Diego Santa Cruz <Diego.SantaCruz at spinetix.com> wrote on 2014/11/28
> > 12:12:56:
> > >
> > > Hi,
> > >
> > > > -----Original Message-----
> > > > From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> > > > Sent: Friday, November 28, 2014 11:05 AM
> > > > To: Diego Santa Cruz
> > > > Cc: panto at antoniou-consulting.com; u-boot at lists.denx.de
> > > > Subject: Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning 
and
> > related
> > > > fixes
> > > > >
> > > > > I have the need to hardware partition eMMC devices from U-Boot 
along
> > > > > with setting enhanced and reliable write attributes.
> > > > >
> > > > > This series of patches adds this support to U-Boot via a new mmc
> > > > > API, a few new members of struct mmc and a new mmc sub-command. 
It
> > > > > also features several fixes to the eMMC hardware partition 
support.
> > I
> > > > > have tested this with Micron eMMC 4.41 parts and it is working 
as
> > > > > expected.
> > > >
> > > > This is really great, thanks.
> > >
> > > Good to know it may be useful to other people.
> > >
> > > >
> > > > I do wonder(I am fairly new to eMMC) about 512B emulation.
> > > > In mmc utils there is a:
> > > > mmc disable 512B emulation <device>
> > > >         Set the eMMC data sector size to 4KB by disabling 
emulation on
> > > > <device>.
> > > >
> > > > I am hoping 4K size will increase performance and reliability?
> > > > Could you add this feature too to your patch set?
> > > >
> > >
> > > I think this was introduced in eMMC 4.51. I do not have any 4.51 
devices
> > at hand to test with but I am not sure there would be any performance
> > benefit to issue reads and writes in the 4KB large sector size. All 
eMMC
> > devices I've seen write in chunks much larger than 4 KB internally 
anyhow
> > (the ones I'm using now have a superpage size of 32 KB). Writes should 
be
> > aligned to the superpage size to get good performance.
> > >
> > 
> > It is in eMMC 4.5 and I asked our eMMC supplier about 4KB, not only 
does
> > 4KB increase performance somewhat,
> > it also has a significant impact on device life.
> > 
> 
> Write size should always be in a multiple of the superpage size to 
maximize performance and life, and the superpage size will be a multiple 
of 4 KB for any reasonable eMMC device. Currently, as far as I can tell, 
the mmc code does the writes in multiple blocks, by chunks of up to 
CONFIG_SYS_MMC_MAX_BLK_COUNT (65535 by default) 512-byte blocks, so data 
is written in sufficiently big chunks as long as the mmc write command is 
issued properly aligned and with a proper length. The eMMC device does not 
have to have committed the data until the end of the multiple block write 
command, so it should buffer up the data to sufficiently large buffers 
before writing them to NAND, lifting most of the performance penalty of 
the 512-byte sectors and, I believe, lifting all the life penalty. For a 
reliable write the situation may be a bit different.

Yes, reliable write is the key(which we need, doesn't everybody? :). This 
is even default for some eMMC devices.

> 
> This being said, I realized that switching to the native sector size is 
a one-time operation that needs to be done before hardware partitioning, 
so yes it would be good to add it to U-Boot. But, as I said, I do not have 
any 4.5 / 4.51 devices at hand to develop this feature with.

You could just "copy" the code from mmc-utils and do a RFC impl. with a 
big fat warning attached to it.

> 
> While writing this I also realized that the current choice of 
CONFIG_SYS_MMC_MAX_BLK_COUNT being 65535 is not good, as writing more than 
65535 512-byte blocks will result in issuing non-aligned writes on the 
second and subsequent chunks when writing 32 MiB or more in a single 
command. A simple fix for this would be to set the default value for 
CONFIG_SYS_MMC_MAX_BLK_COUNT to 65280 (i.e. aligned to 256 KiB) so that it 
is aligned to any reasonable superpage size. A more elaborate fix would be 
for b_max to be rounded down to a multiple of the superpage size read from 
EXT_CSD in mmc_startup().

yes, you could consider 4 MiB alignment as well, 
http://lwn.net/Articles/428584/