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

[Diego Santa Cruz]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund at transmode.se]
> Sent: Friday, December 05, 2014 10:46 AM
> 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
> 
[snip]
> >
> > 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.
> 

Then I leave it as an exercise for the reader :-) Note that after setting a 4 KB device to its native sector size you cannot issue any read nor write whose offset or size is not 4KB aligned, I do not know if all U-Boot code is currently capable of this, otherwise the mmc read / write code needs to emulate unaligned accesses.

> >
> > 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/

It seems to me that 4 MiB alignment for breaking up a large write into chunks is overkill. It is the user of the eMMC that should take care to align things to 4 MiB or similar. I guess it would be even better to align the things to the write protect group or erase size.

I'll cook something up for this issue as soon as I have some spare time.

Best,

-- 
Diego Santa Cruz, PhD
Technology Architect
spinetix.com