We here at Datalight are seeing a lot of interest in this weeks “Software Perspective on eMMC” presentation, across a broad spectrum. This is apparently a pretty hot topic!

If you are interested in joining us, seats are still available – http://www.datalight.com/welcome/web-seminar-switching-to-emmc

A recent article by Doug Wong compared performance characteristics of eMMC and ONFI specification EZ-NAND, specifically Toshiba’s SmartNAND here: http://www.eetimes.com/design/memory-design/4218886

One consideration I would add to this quite excellent summary is about the availability of drivers. Raw NAND has been around for quite a while and the market supplies a large range of drivers. Many of these will utilize the basic functionality of SmartNAND and other EZ NAND chips with only small modifications. Drivers for eMMC, on the other hand, are much harder to find. Only Linux has a freely available driver, which Google’s Android has taken advantage of in recent releases.

At Datalight, we continue to be excited by both of these new technologies. From the JEDEC eMMC parts, the cool features such as Secure Delete and Replay Protected Memory Block are very exciting. On the other hand, the sheer performance of Toshiba’s SmartNAND and other EZ NAND solutions is very much in demand.

Lately you may have noticed a lot of talk about eMMC on our blog and website. If so you may be thinking, “Why is Datalight so excited about eMMC?” Here are 5 top reasons we’re jumping on the eMMC bandwagon:

#5) Standards: Having a standard specification for hardware like eMMC enables our customers to spend less time integrating new hardware and more time focusing on their core competencies.

#4) ECC: As NAND flash lithography shrinks and density increases, error correction has become exponentially more complex and therefore difficult to do in software. Performing ECC in the hardware, like eMMC (or OnFI EZ-NAND parts like Micron’s ClearNAND), overcomes this problem and offers much simpler integration.

#3) Performance: In combining an accepted standard with on-board ECC, eMMC offers excellent performance and flexibility for customers.

#2) Advanced features like secure delete: With more critical data being stored, data security is becoming a much bigger issue. We’re happy to see a standards body like JEDEC focus on tackling this problem. And since customers will need a file system capable of enabling this feature, we’re delighted to be the first to offer support for eMMC 4.41 features like secure erase and secure trim.

#1) Customers: More and more of our customers are either evaluating or using eMMC. Whenever we see our customers using a new technology we ask ourselves how we can help enable them to take full advantage of it. Exploiting the features of eMMC at the file system level is a win for all of us.

Learn more about Datalight flash management solutions

If you’ve noticed the numerous posts lately on the Datalight blog regarding JEDEC and eMMC, you might be wondering why we’re so excited about this particular standard. There are many features that this “smarter” memory will enable for OEMs; In this post I’ll focus on one of those features in the eMMC specification –secure delete.

Securely deleting information on flash memory is more complicated than it seems. For one thing, files are constantly being moved around to ensure even wear of the flash, resulting in multiple copies of file data on the media. Furthermore, when a file is marked for delete, it is typically not physically deleted, rather the space is only marked as available to be overwritten. Until that happens, the “deleted” data is still present and recoverable on the media. In fact, the University of California San Diego Non-volatile systems lab has produced an in depth study of file deletion on flash memory, where they found significant data still present on the media even after deleting the files. A copy of the report can be found at: http://cseweb.ucsd.edu/users/swanson/papers/Fast2011SecErase.pdf

In order to securely delete a file on raw flash, you must use a controller that will either track every block where the file has been stored, or will overwrite the space the file was stored in each time it is moved. The latter describes exactly the secure erase and secure trim features found in the eMMC 4.41 standard. This means that the hardware will finally be capable of securely deleting files –brilliant! There is just one problem: Who has software to support this functionality? As of this writing, there is no file system which supports the feature. While an application can make a call to the media to delete a file securely, the file system may have a backup copy stored somewhere. Fact is, the file system must support the secure delete capabilities of the hardware in order for these features to function correctly.

If an OEM wants to take advantage of the secure erase and secure trim features, their application will need to communicate with the eMMC driver, which may differ from part to part. As the only software company that is an active member of JEDEC, we are excited offer support for quite a few eMMC features. File system support for secure erase and secure trim will be coming later this summer!

Learn more about Datalight Embedded File Systems

The topic of storage technology seemed to be everywhere at last week’s Embedded Systems Conference in San Jose, appearing in numerous key note speeches, presentations and exhibit booths.  It appears the industry is waking up to the difficulties of storing and managing a torrent of data being produced by new mobile applications.

Micron’s presence both on the show floor and conference sessions highlighted their philosophy of creating application-specific storage technologies. In particular, Tom Eby’s keynote address considered both ends of the device and storage spectrum, dividing the market into devices that run applications and those that don’t, that is, devices that demand LOTS of Storage and those that run on meager memory systems (i.e., feature phones).  An interesting side note for Micron customers, Tom announced Micron’s Product Longevity Program (also referred to as PLP) which assures developers availability of Micron flash parts for a 10 year period – especially helpful for makers of long-life-cycle embedded products. Also from Micron, Wanmo Wong gave an excellent presentation on flash file system options for Linux and Android in which he expounded a laundry list of questions that must be answered when making that selection. It was just the right amount of detail for a Linux and flash memory newbie, highlighting the sheer number of issues that must be addressed when selecting the right flash file system for a particular application.

The Woz’ (Steve Wozniak, chief scientist at Fusion-IO) gave a lively fireside chat on the challenges and roadblocks for passionate engineers, from societal problems like our school systems’ failure to nurture brilliant engineering minds, to the difficult balance between getting a (sometimes tedious) job done and following your engineering passion.

Virtually every storage technology was on display from the embedded storage vendors around the globe, from PCM (Phase Change Memory) chips, to eMMC 4.41 parts, to on-board storage, USB and 2-1/2 inch HDD form factor solutions.  Flash storage solutions were presented by Apacer, Innodisk, Viking, STEC and others.  In a sea of slick memory packaging, the Viking example below really screamed embedded to me…

On the Android front, Datalight demonstrated how open source and great proprietary solutions can come together and give developers the best of both worlds. Our temporary home in booth 2320 featured this sneak preview of our upcoming Android support on a TI Beagle board. The tiny-but-slick Android demo is shown at Jimm’s right elbow.

Learn more about Datalight products for Linux/Android

The hot topics in the consumer electronics segments today are Android, installable applications, sexy user interfaces, sensors like GPS receivers, gyroscopes and accelerometers and larger capacity/smaller size storage. Ever since I read Roy’s blog post on CES, I’ve been asking myself when we’ll start seeing the impact of trends in consumer electronics on the more general embedded market. Just as buying a car causes you to see that model everywhere, it seems like asking the question has made it so. In the past few weeks we’ve seen a dramatic increase in the number of customers considering a move from traditional RTOS’s to Linux – more specifically, Android. Many are in the “tire kicking” stage and may never make the switch, but the tide has clearly turned in that direction. The appeal seems to be a combination of user interface – which becomes more important as data use, which has also taken a leap skyward on embedded devices, increases – and ease of application development, perhaps even leveraging the burgeoning application marketplaces that have developed around smartphones. Then again, much of what’s happening in the consumer electronics space is old hat in embedded systems: working in resource constrained environments, power efficiency and dealing with ruggedness requirements.

I guess the real migration is that consumer electronics are combining technologies proven in embedded into multifunction devices, smaller packages with slicker form factors to meet the trendy demands of consumers.

Learn more about Datalight for Linux

The JEDEC eMMC 4.4 specification added two variations to the basic erase command for data security. These were:

Secure Erase – A command indicating a secure purge should be performed on an erase group. The specification states that this should be done not only to the data in this erase group but also on any copies of this data in separate erase groups. This command must be executed immediately, and the eMMC device will not return control to the host until all necessary erase groups are purged. One erase group is the minimum block of memory that can be erased on a particular NAND flash.

Secure Trim – Similar to Secure Erase, this command operates on write blocks instead of erase groups. To handle this properly, the specification breaks this into two steps. The first step marks blocks for secure purge, and this can be done to multiple sets of blocks before the second step is called. The second step is an erase with a separate bit flag sequence that performs all the requested secure trims.

This feature was changed in the eMMC 4.5 specification, due out later this year, and neither of these commands will be functional. To properly handle this change and allow a board design to support multiple types of eMMC parts, the file system or driver will have have a built in flexibility. The alternative, assuming both eMMC vendor drivers work in the design, is still a complete recoding phase and full software test cycle.

Learn How Datalight is Supporting eMMC

JEDEC, the Joint Electron Devices Engineering Council (see http://www.jedec.org), is a group of manufacturers and suppliers collaborating to create specifications for Flash memory access and parts. The current revision of their specification for Embedded MultiMedia Cards, eMMC, is 4.41, and is available on the website above.

I’m excited to be a part of Datalight and JEDEC, and am looking forward to the upcoming eMMC 4.5 and UFS 1.0 specifications. Datalight is not in the business of manufacturing hardware, of course, but our file system products like to work closely with the underlying driver. Until those products are fully eMMC 4.5 compliant, what can you expect?

The most fundamental thing a Reliance file system needs is a block device that writes data when it says it will. Any data left in a cache or not flushed upon command could be lost data in an unexpected power loss. The Enhanced Reliable Write feature means any eMMC 4.41 or 4.5 flash part will work perfectly with Reliance and Reliance Nitro.

The High Priority Interrupt feature of eMMC basically means that a block device write might pause, reporting back only a partial write. This is fully supported in the Reliance Nitro file system, which will then loop back and continue the write after the HPI is complete.

The Trim feature of eMMC 4.4.1 is being replaced by a Discard feature in eMMC 4.5. The latter fits in more closely with the way Reliance interacts with our own FlashFX product.

Basic functionality (Read, Write, and Erase) is of course supported, and full compliance with eMMC 4.5 is on Datalight’s roadmap, so keep an eye out here for more news soon.

Palm just announced the 1.1 update to its popular WebOS that runs on the Palm Pre device. Apple released the 3.0 update to its Mac OSX for the iPhone and iPod touch. Microsoft is expected to launch Windows Mobile 6.5 soon and users are hoping that they will be able to update their 6.1 devices to 6.5. Google last month updated Android OS to 1.5. These events point to a recent and very fast growing phenomena: embedded devices are becoming more and more like PCs where users expect to be able to update their device long after it has been released. This was not always the case; OEMs refrained from updating embedded devices unless in cases of high severity bug fixes. There are several reasons for this:

1. Updating embedded devices is more difficult than updating PCs from a distribution standpoint
2. Because of #1, updating devices is also expensive
3. Potential of bricking devices (device does not boot anymore) due to user error is very high leading to high risk of warranty returns

Today’s blog post focuses on #3 because it has very real technical risks and solutions. Before we begin discussing risks of bricking device, let’s talk about 2 different types of updates

1. Update to application code – This is usually much simpler and does not typically involve changes to the bootloader or the boot image
2. Update to system code/OS image – most of the times when OEMs have to update devices, it is due to some severe error. In our experience it usually involves changing system files. If the entire OS is stored as a single image on disk/flash, then entire image has to be correctly replaced with the new one

If the update is of type 1, then the process has less likelihood of bricking the device. In most cases even if the update fails, support can help user start the device in “safe” mode and restore. Updates of type 2 are by nature riskier because any failure is likely to stop the device from booting up, negating any remote debugging options. Note that It is also possible that for some devices, the application and system code is stored in single boot image. In that case, the distinction of types made above are irrelevant for this discussion.

OS/System Updates

Here is how devices typically partition the data storage for boot and application data

Note: Some devices may not use the file system for the boot partition and instead directly talk to the block device. In that case, the remainder of this discussion is not applicable.

During an update process involving system code, the boot image has to be replaced with a  new one. Typically the update process will overwrite the existing image. The problem happens when the update process is interrupted due to erroneous circumstances such as

1. Device battery dies before the update process is completed
2. The user pulls out the USB cord connecting the device to host

In these cases, the OS image will get corrupted and the device may not be able to boot back up, leading to a bricked device.

One of the features of Reliance (and Reliance Nitro) file system is that it never overwrites live data. It will always use free space on disk or in case there is no space, it will give “disk full” error back to the application. Reliance also has a special transaction mode called “Application-controlled”. In this case, Reliance only conducts a transaction point when asked by the application. Here is how these 2 constructs help Reliance provide a fail-safe means of in-place updates

1. The OS image is stored on a Reliance partition
2. The update application calls Reliance API to disable all transaction modes. Reliance will now execute a transaction point only when specifically called by the update app
3. The update app starts “overwriting” the existing OS image. Because Reliance never overwrites live data, it will start copying the new image to free space on disk
4. In case power is interrupted, Reliance discards the new image and device can still boot back to the old OS image and restart the update process
5. Once the entire update process is completed, the update app calls Reliance to execute a transaction point. Reliance, in one atomic operation, updates its committed state to now use the new image. When the device boots back up, it now uses the new image. The old image is now marked as free space by the file system

Using Reliance for boot partition can thus help in providing a safe in-place update process. It also has the advantage of using Reliance extreme fast mount times, which can help in speeding device boot speeds.

Note that the obvious caveat of the above is that there has to enough free space for the new OS image. With disk storage being cheap (compared to device cost) and always increasing, this becomes less and less of an issue. OEMs should strongly consider going this alternative (whether they use Reliance or not) in order to ensure that the device update process will go smoothly for the end users.

We have talked about managed NAND in a few blog posts before. Usually a combination of raw NAND flash (SLC or MLC) combined with a hardware controller that performs flash management features like bad block management, ECC and wear leveling is referred to as managed NAND. The term covers a huge spectrum of flash-based storage devices so in this post we will try and highlight some of the more prevalent types of managed NAND

The following is an enumeration of some of the popular managed NAND form factors. Please note that the list covers flash technologies used for resident storage and does not cover removable storage like USB flash, SD, etc.

•    eMMC
•    eSD
•    CompactFlash
•    Solid State Drives
•    BA NAND
•    Adaptable NAND
•    Specialized
–    Specially designed controller + raw flash

CompactFlash is included here because it is used both as resident and removable storage. CF comes with a Fixed-drive option which allows it to be used a resident managed NAND.

The above technologies differ from each other on several attributes

•    Form factor – managed NAND can come is several form factors. An SSD may sport a standard 2.5” drive enclosure whereas a CF card will take a 1.0” card form factor.
•    Plug-in interface: What interface does the managed NAND use to connect to the device platform
–    MMC
–    SD
–    ATA
–    Custom
•    Cost: Cost depends on several elements
–    Type of flash used: SLC is much more expensive than MLC
–    Type of controller used: consumer grade controllers (used for consumer grade CF for example) are much cheaper than specialized industrial grade controllers
•    Performance
–    Performance varies depending on the flash type, the controller attributes and the interface.

Some of the big players in the managed NAND business are

•    eMMC
–    Micron, Numonyx
•    eSD
–    SanDisk, Toshiba
•    BA NAND
–    Toshiba
•    Solid State Drives, CompactFlash
–    Too many players in these markets

This was a brief view of the managed NAND landscape. If there is interest, we will do a follow up going in details about the specific categories and interfaces