Bothell, WA, – March 18, 2010 – Datalight announces support for Linux kernel versions up to 2.6.29 with new versions of FlashFX Tera, the file-system independent flash memory driver and Reliance Nitro, the highly-reliable, high-performance file system. FlashFX Tera version 1.2 offers out-of-the-box support for over 300 different flash memory parts from all the leading suppliers, expanding the choice for OEMs using flash memory. Linux is finding its way into more devices such as smart phones, automotive infotainment, and industrial equipment which require both responsiveness and 100% data reliability, by adding Reliance Nitro 1.2, OEMs can ensure rock-solid reliability of their systems without paying a performance penalty.

“Datalight continues to raise the standard in delivering advanced file system features for MontaVista Linux,” said Dean Misenhimer, Director of Marketing at MontaVista Software. “Our partnership provides our customers the option of a pre-integrated professional flash file system solution to speed their development of flash-based devices. This ultimately leads to faster time to market with superior performance and reliability.”

FlashFX Tera supports the full range of flash technologies including NAND, NOR, and MLC NAND flash in a single driver. Its patented wear-leveling and bad block management extend the useful life of devices using flash. While FlashFX Tera can be used with virtually any file system, pairing it with Reliance Nitro provides an optimized data storage software stack to simplify system development.

Reliance Nitro version 1.2 also adds support for extended file attributes. Most commonly used to designate file permissions, extended attributes are important to customers using special Linux distributions like SMACK. As data quantity and complexity in devices grows, extended file attributes can also be used for storing additional metadata (data about the data), such as digital rights information, GPS location or any information that makes finding and using the data easier. The ability of Reliance Nitro to serve as the root file system for Linux can simplify the data storage stack for these devices by allowing them to operate with a single file system.

“With the growth in adoption of Linux for data-intensive embedded devices, OEMs need a flash file system that better supports their reliability and performance requirements.” said Roy Sherrill, Datalight CEO. “By migrating our flagship products to Linux we’re filling that gap in the market with a robust, commercial-grade solution backed by our reputation for responsive, high-quality support.”

FlashFX Tera 1.2 and Reliance Nitro 1.2 are available immediately from Datalight and the Datalight worldwide network of channel partners. Please visit us at datalight.com to find a reseller near you.

The Reliance family of file systems and FlashFX family of flash media managers comprise the Datalight flash file system solution. Reliance was designed from the ground up for high reliability applications. Dynamic Transaction Point™ technology gives developers full control over performance and data protection characteristics, protecting users from file system corruption, even after unexpected system interruption. Embedded applications can benefit from faster boot times that remain consistent for the life of the product, regardless of disk size. FlashFX™ Tera features pre-written support for over 300 flash parts, works with virtually any NAND controller, and features wear leveling, bad block management, and background compaction for unrivaled performance.

Watch Rob Hart demonstrating the Datalight flash file system on the Beagle Board with Windows CE 6.0

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.

Ever since we announced our high performance file system Reliance Nitro, we have been getting questions on how it compares to the original Reliance file system. Below is a quick-reference table noting some of the differences between the two. For a more detailed comparison (including performance benchmarks), please contact us.

With the release of our new file system this week, Reliance Nitro, we asked our Account Managers what they liked most about our new product. Their answers of course included reliability and high performance. Wes Johns and Phillip Allison were so excited they decided to make a video…  watch the youtube video

We’re totally psyched about Reliance Nitro, our newest file system (yes, we’re file geeks), and we’re always on the lookout for opportunities to show off the performance and reliability attributes it adds to Windows Mobile and Windows CE. When we discovered the relatively-new Beagle Board, it occurred to us that a small, low-cost platform might be just the thing to demonstrate Nitro’s amazing benefits. As you’ve probably heard, the Beagle is making waves with its low cost (around $150) and diminutive size. It uses an OMAP 3530 processor and 256MB of NAND. Though they are most commonly used with Linux, we lucked out in having a partner (MPC Data) who has already developed a Windows CE BSP for it. After a few phone calls, the wizards at MPC Data were able to develop a slick video playback demo app, and presto, the Reliance Nitro Beagle Demo was born! Amateur videographers that we are (ok, REALLY amateur), we recently videotaped John Burnham, who has been working on this project on the Datalight side (and who is a really good sport, btw) showing what happens when power is interrupted during a file write and the extra reliability factor of Reliance Nitro on Windows CE. Be sure to check it out here.

Datalight Reliance includes unique technology called Dynamic Transaction Point ™ which provides the flexibility and control device manufacturers need to tune the performance of their device. It enables multiple configurations that can run simultaneously to provide scenario-specific performance optimization. To highlight this technology, we have added a section to Datalight’s website to describe some common embedded devices and the corresponding file system tuning attributes for each of them

www.datalight.com/filesystemtuning

SanDisk recently announced that it is end-of-lifing several flash parts in the mDOC family and OEMs who were using these parts in their devices are now looking at viable alternatives.  In order to help these affected customers make informed decision, we have published a new whitepaper on options for migrating from Sandisk mDOC flash family.

The paper is available at http://www.datalight.com/mdocwhitepaper/

There are two possible configurations in how boot code might be stored on a device

1. Boot code is stored in raw flash (no file system) and directly accessed from bootloader
2. Boot code is stored on a Reliance formatted flash volume

Option 1: Raw flash
If the boot image is being stored in RAW flash outside the file system, then the only way to be able to ensure that you got an update without damaging the original would be to reserve extra RAW space such that you could simultaneously have two boot images. The bootloader now needs to be able to switch between them and/or locate both of them The process of updating the boot image to a new location would include erasing the old image after updating the new, and having some sort of checksum to ensure the image was intact in case both were still there.

In this case, there would be no really good way to protect the update of the file to that exact same location without compromising the boot image itself. Many customers still use this way to store their boot images, but of course this means that they can’t take advantage of disabling transactions, atomically updating the boot image, and then doing a single transaction to commit all (or none) of the changes.

Option 2: Reliance
In this case, customer would not have a bootloader that checked a physical location for a boot image – they would have a bootloader that opened a file in the Reliance file system at boot time instead, if they were using a file system. Datalight Reliance comes with an utility called “Datalight Loader” which includes a lightweight Reliance reader. This utility integrates seamlessly in your bootloader code and allows the bootloader to mount and read Reliance partitions. Since the bootloader is capable of “reading” a Reliance disk, it doesn’t care where in the file system Reliance stores the file – it just opens the file, and loads it.

In this mode, while updating the boot image, the update utility disables all transactions and initiates the boot image update. Reliance never overwrites live data and hence this new boot code is written to a free-area of the flash. Once the entire boot image code is written, the bootloader calls for a manual transaction event, in which we update the metaroots to point to the new boot code area as the committed area. Old boot code area is now marked as free and can be used for future operations.

If power loss occurs during this replacement process, the device still boots back using the previous boot image, which was never modified

Demonstrating how system software work in a visual manner is an interesting problem, especially in embedded space. There is no UI or visual effects to WOW the audience. To evaluate the value system software components bring to an embedded design, the customer usually needs to configure our software on his embedded development board. This provides for comprehensive evaluation but can be a significant effort. . We run into this very often at Datalight since our primary products (FlashFX Pro and Reliance) are system level embedded software. One way we have attempted to demonstrate our software is to make a full-functional version of our software run on user’s desktop PC. This allows the customer to run the software without any special hardware in matter of minutes and understand the core working of our software. Once they believe there is value, the can request source code access and try it on the actual embedded hardware.

The first demonstration that we have built is for Datalight Reliance. This demo is available to all users who are registered for MyDatalight account. The video below shows how you can use this software on any Windows PC and understand how Reliance unique transactional design allows for 100% reliability against data corruption and how Dynamic Transaction Point technology allows developers to tune their file system even while the device is running.