original article published in March, 2007
EETimes recently ran an article titled “Plummeting prices make NAND appear almost free” (http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=197002923). 1GBytes parts cost around $55 in Nov 2005. As of 2007-03-28, a 1GBytes part costs around $8. This is almost an order of magnitude reduction in a little over a year. This article examines the impact this price drop will have on embedded systems and the changes we will likely see including: storage is now at post-scarcity, will “embedded” distributions become obsolete, will uclibc become obsolete, and challenges with large NAND flash parts.
3 major components in an embedded computer
The 3 major components in an embedded computer are:
- processor
- RAM
- Flash Storage
All of these components have been gradually decreasing in price over the years, and there has been a corresponding gradual increase in the use of complex embedded systems. However, the drop in NAND flash in the last year represents more of a step change, and will likely result in some more drastic changes.
We are to the point of post-scarcity for Flash storage
Up to this point, most full featured embedded Linux systems contained 16-64MB of NOR flash. A full featured graphical Linux terminal requires about 20-30MB of flash disk space just for applications and libraries. So, in the past we were still concerned about application footprint. The was a lot of incentive to not cross the 32MB to 64MB boundary, etc. With 1GiB of flash now costing less than $10, we essentially have unlimited flash storage in the context of an embedded Linux distribution. We will probably see the following:
- faster time to market as we need to spend less time optimizing
- increased use of GTK+ as the standard GUI toolkit. We no longer care how much space GTK+ takes.
- more debugging features can be left in the production system. Why not leave VIM, Minicom, and SSH in the build if we have plenty of space. These non-critical features will lower the cost of maintaining a product.
Will “embedded” distributions become obsolete?
There has always been a great deal of interest in running Debian and other “standard” distributions in embedded systems. With 1GiB of storage, this is going to be a lot more practical. However, with a little experience, you soon realize that distribution size is only one of the many factors. Another equally important factor is the ability to easily automate the build process for the entire project, including custom applications and image generation for programming. With complex systems like Linux, it is easy to get into the hack-n-slash mode where it takes a lot of manual steps to build the system. While this may seem OK when you building the system, it ends up causing a lot of pain and errors once you get in a hurry, of down the road when you are trying to maintain the system. Ability to easily customize the distribution is another requirement. OpenEmbedded (http://openembedded.org), and other build systems provide these features. I think we will see a big increase in Debian and other standard Linux distributions in Embedded systems, but OpenEmbedded and other embedded build systems will continue to grow in use as well because there are many factors in the equation. This is the nice thing about open source — use what works best for you.
Building and maintaining an embedded system is a lot different than setting up and maintaining a desktop or server system. Other articles related to this topic include: http://bec-systems.com/web/content/view/63/9/ and http://bec-systems.com/web/content/view/35/37/.
Will uclibc become obsolete?
Because flash is now cheap, why do we need to use uclibc (small footprint libc) — can’t we just use glibc. For full featured embedded Linux systems, this argument makes sense. However, there is push toward higher integration at the low end. Many companies are offering 32-bit “microcontrollers” with integrated flash and RAM. The processors in these devices are more than capable of running Linux. The limitation to date has been the RAM and Flash size. The available memory in 32-bit microcontrollers will increase over time enabling them to run a low end uclibc based system. The idea of running Linux on a system that is composed of a single chip is very interesting.
Challenges with large NAND flash parts
What challenges will using large NAND parts present? In general, dealing with NAND is a lot more complex than with NOR flash. For reading, NOR parts present a simple memory mapped interface. A NAND interface is not memory mapped and looks more like a FIFO or a Hard Drive interface. This makes booting from NAND flash much more difficult. Some parts present a memory mapped interface for an initial loader. Some processors build NAND flash bootloading into the processor. Other systems boot from a small NOR flash and use NAND after the system has booted.
Filesystems are also a challenge with NAND flash. The standard method is to use JFFS2 which was designed for smaller NOR parts. JFFS2 works well, but is a log based filesystem. This means it has to scan the entire file system on mount and store the entire inode chain in memory. This takes lots of time and uses lots of RAM. For small devices (64MB), this is tolerable, but for large devices the mount time can take 10’s of seconds. YAFFS2 is another log based flash filesystem designed specifically for NAND flash which includes a feature called checkpointing that bypasses the normal mount scanning. Another development is LogFS which looks promising, but will probably not be ready until mid/late 2007.
Programming NAND flash can also be a challenge. Because NAND flash can contain bad blocks, programming is a lot more complex. Traditionally, flash programming in a NOR system was done by the bootloader. For a system that boots from NOR flash, programming the NAND flash can be done from a small Linux system (see http://bec-systems.com/web/content/view/66/9/). If you are booting from NAND flash, programming may be done with a JTAG programmer that supports NAND flash, or by downloading a small bit of bootstrap code into the processors internal memory using JTAG, and this bootstrap code then has enough functionality to program the NAND flash.
Summary
The lower NAND prices will bring about change in the way embedded systems are built. Please comment if you have addtional ideas or observations.