[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: 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.

NAND chips nowadays use pages which are usually 8 KB and NAND pages must be written in their entirety, so even writing in chunks of 4 KB will incur a penalty if the write command is stopped every 4 KB. Furthermore, larger capacity devices use several NAND chips in parallel which makes the effective page size be the NAND chip size multiplied by the number of NAND chips, this is what the superpage size is.

My guess is that 4 KB page devices may arrange the ECC differently when in native mode and may also arrange their internal block mapping metadata differently as well, leading to a performance improvement.

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.

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().

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