OEM customers have told us for years that struggles with NAND supply and lack of standards costs them a great deal of time and money. A shortage or EOL on a key component like NAND flash memory can cause product delivery delays that impact topline revenue and potentially company reputation. What they wish for is a "plug and play" option that lets them multi-source their flash memory. For years Datalight has provided a software standard to make parts switching less painful, but the lack of hardware standards continued to plague our customers.
As you might expect, many are excited by eMMC because it promises to address a big concern with supply chain and parts availability. By adopting this hardware "standard", OEM's believe they will be free from vendor lock in - that is compelling. They and their ODM suppliers can source parts from whichever vendor is closer, has available supply or is easiest to work with. Powerful stuff for negotiating cost of goods.
However, the inconvenient truth is that though eMMC is a hardware standard that ensures pin-compatible alternatives from a plethora of suppliers, there are so many exceptions and vendor-specific variants that substantial software modifications are still required. You will likely find a driver from a BSP provider that enables their board or processor to work with eMMC - at the most basic level. This purpose-built software will be provided in un-modifiable binary form written expeditiously to "check the box" for eMMC support. It is unlikely that the supplied driver will work as-is with special capabilities in parts from another vendor (or even with the next die shrink of the first vendor's parts!) Then starts the quest to either get the software updated by the BSP provider or negotiate for source code access and invest in making the changes yourself. Can you say "schedule impact"?
Another potential shortcoming was pointed out to me recently by a long time FlashFX customer -- "how do you know how effective the wear-leveling is when it's all done inside the black box?"
Ideally, the driver you use with your eMMC should be intelligent enough to assess the vendor-specific features available, the wear-leveling effectiveness and be provided in source code so you can make any modifications for as-yet-undefined capabilities of your hardware. And if you could have everything you wished for, the driver would be written by flash-vendor-neutral software and flash technology experts. Hmmm. I think I know some of those.