Feed aggregator

Last month’s ware was a machine for making custom card-edge connectors for game cartridges. The machine is made by AUK Contractors, a Taiwanese connector company with factories in China. AUK is on my short list of suppliers for volume quantities of connectors. Their ability to make highly automated machines like this is rare in China, and their extraordinary sophistication in automated manufacturing allows them to maintain quality while hitting price points many other manufacturers can’t touch.

Below is a video of the machine in operation (caution: the machine is very loud, I recommend adjusting the volume down before hitting play).

You can also watch in HD (24 MB).

I can stare and watch machines like this operate for hours. I’m particularly fascinated by the vibrating buckets that, through simple shaking motions, takes a random pile of connectors and lines them up. The vibration of the bucket is biased; if you put your hand on the edge of the bucket, your hand will also magically glide in the same direction as the connectors. There are a series of notches and ledges on the internal guide tracks that cause connectors in the wrong orientation to fall back into the bucket, such that by the time connectors reach the top they are all in just one orientation.

I believe that this machine is making the connectors used by the Leapfrog Leapster series of handheld educational game consoles. Arnuschky was the first to guess a game connector, and thus is the winner. Congrats, email me for your prize!

Machine Log is an excellent blog about restoring ancient video and audio equipment and sometimes building rad projects too. I love the attention to detail and appreciation for the forgotten age of beautifully tied off colour coded wires and hand drawn copper traces.

http://crochambeau.blogspot.com/search/label/video
http://binauralaboratories.blogspot.com/

A project that recently caught my eye is a 360 degree rotating cradle to allow point unrestricted tilting of a video camera for video feedback. This is an incredibly useful project as there are literally thousands of permutations and patterns available by changing the angle of the camera and screen.


















Also this modular video processor is an interesting piece of broadcast kit

https://www.youtube.com/user/wsadhu
"This video shows my first tests of analog video switching in sync with music.
The analog clock pulses come from arduino programmed to convert midi input to analog signals (CV, GATE, CLOCK, RUN/STOP).
The video switch itself and the output monitor have no v-sync therefor images in screen tend to be verticaly shifted. It should not be a problem with most modern signal recievers,
thou for fast switching a digital syncing of all signals can be added"

Director, Editor: Aurora Halal
Camera Assistant: Ethan Goldwater
LZX video synthesizer magic: Michael Potvin
Dancers: Angela Chambers & Angelina Dreem
©2013 RVNG Intl./ www.igetrvng.com
http://ptvn.net/
more of Michael Potvin's work for a band called Motion Studies here

http://monochrome-movingimages.com/
https://vimeo.com/mademoisellekardinal

Sabrina Ratté video for Suuns, using some very nice waveform generation and feedback to great minimal effect, Inspiring 
Suuns - "2020" (Official Video) from the album 'Images Du Futur' out March 5, 2013 on Secretly Canadian and on Secret City in Canada

MicroPeak USB Interface now available.

Altus Metrum is pleased to announce the immediate availability of the MicroPeak USB interface.

• Connects the MicroPeak altimeter to USB.

• Records 48 seconds of flight

• Barometric pressure values recorded about 5 times per second.

• Save, graph and export pressure, height, speed and acceleration data.

• Supports Linux, Mac OS X and Windows. The software is available on the MicroPeak web page.

• Learn more at http://www.altusmetrum.org/MicroPeakUSB

• Buy these for $35 at the gag.com web store for Altus Metrum products. Or get one bundled with a MicroPeak and save $10.

MicroPeak USB Interface

MicroPeak and the MicroPeak USB Interface

MicroPeak is fun to use all by itself, providing a quick way to know how high your rocket has flown. But, for those people itching for more data, MicroPeakUSB offers a way to download raw flight data and analyze that on your computer.

MicroPeakUSB doesn’t require any changes to the MicroPeak hardware—new MicroPeak firmware transmits the entire flight log through the on-board LED to a phototransistor on the MicroPeakUSB Interface and then to the USB port on your computer.

Existing MicroPeak owners can contact us for a special deal on the MicroPeak USB interface and upgrading the MicroPeak firmware.

For the better part of a year, this blog has failed to provide you with a lot of updates what I've been doing. This is somewhat relate to a shift from doing freelance work on mainline / FOSS projects like the Linux kernel.

In April 2011, Holger and I started a new company here in Berlin (sysmocom - systems for mobile communications GmbH). This company, among other things, attempts to provide products and services surrounding the various mobile communications related FOSS projects, particularly OpenBSC, OsmoSGSN, OpenGGSN, but also OsmocomBB, and now also OsmoBTS + OsmoPCU, two integral components of our own BTS product called sysmoBTS.

Aside from the usual software development, this entails a variety of other tasks, technical and non-technical. First of all, I did more electrical engineering than I did in the years since Openmoko. And even there, I was only leading the hardware architecture, and didn't actually have to capture schematics or route PCBs myself. So now there are some general-purpose and some customer-specific circuits that had to be done. I really enjoy that work, sometimes even more than software development. Particularly the early/initial design phase can be quite exciting. Selecting components, figuring out how to interconnect them, whether you can fit all of them together in the given amount of GPIOs and other resource of your main CPU, etc. But then even the hand-soldering the first couple of boards is fun, too.

Of all the things I so far had least exposure to is casing and mechanical issues. Luckily we have a contractor working on that for us, but still there are all kinds of issues that can go wrong, where unpopulated PCB footprints can suddenly make contact with a case, or all kinds of issues related to manufacturing tolerances. Another topic is packaging. After all, you want the products to end up in the hands of the customer in a neat, proper and form-fitting package.

On the other hand, there is a lot of administrative work. Sourcing components can sometimes be a PITA, particularly if even distributors like Digikey conspire against you and don't even carry those low quantities of a component that we need for our 100-board low quantity runs. EMC and other measurements for CE approval are a fun topic, too. I've never been involved personally in those, and it has been an interesting venture. Luckily, at least for sysmoBTS, things are looking quite promising now. Customs paperwork, Import/Export related buerocracy (both in Germany as well as other countries) always have new surprises, despite me having experience in dealing with customs for more than 10 years now.

Also significant amount of time is spent on evaluating suppliers and their products, e.g. items like SIM/USIM cards, cavity duplexers, antennas, cables, adapters, power amplifiers and other RF related accessories for our products.

The thing that really caught me off-guard are the German laws on inventory accounting. Basically there is no threshold for low-quantity goods, so as a company on capital (GmbH/AG) you have to account for each and every fscking SMD resistor or capacitor. And then you don't only have to count all those parts, but also put a value at them. Depending on the type of item, you have to use either the purchasing price, or the current market price if you were to buy it again, or the price you expect to sell the item for. Furthermore, the trade law requirements on inventory accounting are different than the tax laws, not often with contradictory aims ;)

In the end it seems the best possible strategy is to put a lot of the low-value inventory into the garbage bin before the end of the financial year, as the value of the product (e.g. 130 SMD resistors in 0402 worth fractions of cents) is so much lower than the cost of counting it. Now that's of course an environmental sin, especially if you consider lots and lots of small and medium-sized companies ending up at that conclusion :(

So all in all, this should give you somewhat of an explanation why there might have been less activity on this blog about exciting technical things. On the one hand, they might relate to customer related projects which are of confidential nature. On the other hand, they might simply be boring things like dealing with transport damage of cavity duplexers from china, or with FedEx billing customs/import fees to the wrong address...

Overall I still have the feeling that I was writing a decent amount of code in 2012 - although there can never be enough :) Most of it was probably either related to OsmoBTS, OpenBSC/OsmoNITB or the various Erlang SS7/TCAP/MAP related projects. The list of more community-oriented projects with long TODO lists is growing, though. I'd like to work on SIMtrace MITM / card emulation support, the CC32RS512 based smartcard OS, libosmosim (there's a first branch in libosmocore.git). Let's hope I can find a bit more time for that kind of stuff this year. You should never give up hope, they say ;)

One of the many faces of digital hardware design entails tracking many files to be fed to multiple EDA tools. The eventual reports or netlists are carefully analysed and logged as part of the sign-off methodology. Each company tracks these project dependent files under a certain directory structure and under a certain revision controlled system of their choice.

The development cycle Fedora Electronic Lab 12 has started. One key feature for the next Fedora 12 release will be improving “collaborative hardware development experience” on Fedora. As a test-case scenario, let’s imagine 4 persons (from 4 different continents) have encountered each other using a particular social networking medium and want to engage into the development of a FPGA project.

While Fedora Electronic Lab already includes the respective simulators for digital design (VHDL/Verilog), waveforms viewers, schematic editors, PCB layout editor and Fedora’s different webserver and security solutions, these 4 persons (test-case scenario) should not have any issue with the latest Fedora 11 release.

For Fedora 12, we want to ensure that these persons have adequate tools to set up a webserver dedicated for hardware design and help them improve their sign-off and code review methodologies. Hardware code review for small inexperienced companies is often misguided and ends up wasting work hours in unnecessary meetings. Designers often have mixed feelings about code reviews. Sometimes when the code review is outsourced to a third party, source codes are sent in the form of tarballs and tracked as tarballs instead of files, which this is no means an efficient way.

We are currently including an efficient and reliable code review solution into the Fedora collection. This free and opensource solution will also help create links and seamless references between bugs, tasks, changesets and files. Project coordinators will have a more realistic the overview of the on-going project and track the progress very easy with respect to different milestones and deadlines.

Coupled with Fedora’s commitment in Virtualization and SELinux, hardware designers will benefit with a free and robust platform which can easily be deployed.

Last week announced the availability of Fedora 11. This new release entails Windows cross-compilers
introduced by Fedora’s MinGW Special Interest Group.

The aim is to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application.

Though this feature will interest a wide range of software developers, I believe EDA vendors will also be very interested. I will demonstrate a quick example of how to use these Windows cross-compilers.

In this demo, I will use gerbv, a gerber viewer and the example “Temperature Collector” developed by Levente Kovacs.

To install gerbv on fedora,

# yum install gerbv

The above screenshot shows gerbv compiled under a normal Linux “configure && make”. Now we will compile the same gerbv for Windows.

1. Download the sources of gerbv.

2. Setup your Fedora 11 Linux

# yum install mingw32-gcc mingw32-gtk2 mingw32-crossreport mingw32-nsiswrapper wine

3. Configure Wine.

4. Extract gerbv sources.

5. Compilation of gerbv for Windows
$ cd gerbv-2.2.0
$ mingw32-configure
$ mingw32-make

The final Windows executable file of gerbv will be stored in src/.libs/ as gerbv.exe together with its DLL file, libgerbv-1.dll.

6. Launch gerbv.exe under wine

$ wine src/.libs/gerbv.exe

7. Test gerbv.exe under windows.

Under windows, extra DLLs are required and these can be downloaded from The GTK+ Project or simply from here.

The gerber files used in this example, my compiled gerbv.exe and libgerbv-1.dll can be downloaded from here.

mingw32-nsiswrapper can later be used for building automated Windows installers for distribution.

I hope this short crash course will help you. For any additional details, please join the Fedora Mingw mailing list or IRC: #fedora-mingw on FreeNode.

References:

• Fedora IRC Classroom – Using the Windows cross-compiler with Richard Jones
• Windows cross compiler Feature wiki page

Everyone has heard of open source software, but can the same principles be applied to hardware?

Some people argue that hardware is so expensive to manufacture and modify that it prevents hobbyists from contributing, and thus stifles the development of an open source hardware community.

This isn’t entirely true. In fact, the huge popularity of community-developed microcontroller platforms (Arduino and its huge collection of add-on modules being the most famous examples) tends to show the opposite. Other examples include the USRP software-defined radio platform, Texas Instrument’s Beagleboard single board computer, or the Openmoko mobile phone (though the latter has enjoyed limited success).

But while those projects feature open and public hardware specifications, ”traditional” schematics, printed circuit boards and mechanical designs, the whole semiconductor design and manufacturing process remains a poorly covered area. There are a few pioneers like GRLIB (LEON3), OpenSPARC and OpenRISC. But all suffer from excessive complexity, slowness and large hardware resource usage – if not outright poor or unfinished design. These factors make them difficult to access and stifle their wide adoption, with a need for oversized FPGAs, modern semiconductor processes and advanced logic synthesis tools – all being very expensive.

The Milkymist project thus develops a high performance system-on-chip (SoC) design with the economy of resources and of complexity in mind. It is targetted at the demanding application of real time video effect rendering for embedded systems, and wants to prove that open hardware logic designs can compete in terms of performance.

The Milkymist SoC is based on Lattice’s Mico32 CPU core, and features a host of custom-developed peripherals, like a DDR SDRAM controller, various I/O interfaces and graphics acceleration.

But Milkymist’s founder, Sébastien Bourdeauducq, said that they are not stopping there. They are developing a complete open hardware product out of this system-on-chip, which includes software, schematics, PCB, and enclosure. The end product will be an “interactive VJ station”, a device meant to be used during concerts and artistic events to generate real time video effects and make them interactive thanks to the many built-in interfaces (MIDI, DMX, video input, Ethernet, OSC, USB, GPIO).

To foster development on this open hardware platform, Free Electronic Lab (formerly known as Fedora Electronic Lab) and Milkymist are collaborating to provide the smoothest and easiest to setup programming environment as possible.

At this time, the full system-on-chip design is complete (the current focus is on improving its documentation and fixing any bug that can be found) and the second batch of PCBs (hopefully based on the final design) is on its way to the fab. If everything goes well, some development kits will be available for sale at the end of December.

For more information, visit www.milkymist.org.

A couple of weeks ago I asked people on my blog and a few chosen mailing lists to answer three simple questions:

1. What monitor calibration devices do you own?
2. Which of these devices have you used in the last 6 months?
3. If you were to buy a new calibration device, which would you buy?

I wanted to work out what hardware I should buy for testing with gnome-color-manager and colord for each release. The results are very skewed toward Linux users, but that was kind of the point of the survey.

So, the first set of data, which 203 people answered:

Notable points:

• Nobody owns a Colorimetre HCFR. Not much of a suprise really.
• Spyder4 is new hardware which performs well, but hardly anyone owns one yet.
• 43% of people answering the survey own a ColorHug, which isn’t too much of a suprise since it was posted on the ColorHug Google+ page. Still, pretty awesome for such a new project.

The next graph is very similar to the first, with 191 people responding:

Notable points:

• There are a lot of Spyder2′s sitting in drawers unused.
• Lots of people bought a ColorHug, and don’t use it very often. This isn’t suprising as it’s the least expensive device by a long way.
• i1Pro owners use the device a lot more than people that own other devices. This is also a very expensive device, so again, kinda makes sense.

The last graph is interesting in a number of ways, from 173 users:

• 52% of Linux users would buy a ColorHug. This is the most popular cheap colorimeter option.
• 31% of people would buy a much more expensive photospectrometer rather than a colorimeter.
• 11% of people want to buy hardware considered obsolete by the manufacturer.
• 2 people want to buy a Colorimetre HCFR. Good luck there
• 6 people wanted to buy a ColorHug Spectro, even though it wasn’t an option on the survey and doesn’t even exist yet.

Based on the results of this data, I think it’s important for me to buy some Spyder hardware and concentrate on the photospectrometer-type hardware. Thanks to all respondents, your help has been really valuable.

 

John of  of now defunct but fantastic blog Destructural Video has organised a screening showing two 1980's videos from the sound art project Nocturnal Emissions who as well as being involved in industrial/electronic music in the eighties were also early pioneers in scratch video.

Thursday, 14 February 2013, Wharf Chambers Ground Floor, 23 - 25 Wharf Street, LS2 7EQ Leeds

http://www.facebook.com/events/407157019370475/ video



"Limerent Objects is proud to present a Sterile Records double bill screening of:

BLEEDING IMAGES (1982, 46 minutes, VHS)
THE FOETAL GRAVE OF PROGRESS (1984, 34 minutes, VHS)

Perhaps THE quintessential audiovisual statements of the post-industrial music scene. Provocative in content, prescient in style, these medium-length videos captured the subversive interests and activities of the pioneering sound art project The Nocturnal Emissions against a contextual backdrop of the UK between 1981 and 1984; a time rife with mass unemployment, civil unrest, media hysteria, political indifference, terrorism and war overseas. Burroughsian cut-ups reveal subliminal imagery hidden in exploitative mainstream broadcasting; shocking images of real-life violence against living beings are critically employed to expose our complacency in everyday cruelty; the thunderous soundscapes and ritual performances of The Nocturnal Emissions awaken the viewer's senses to our undermining culture controlled by fear and repression...

Rarely viewed since their initial home video releases and screenings at the Tate and ICA in the UK as a result of the imposing 1984 Video Recordings Act, both videos remain impressive today as early influential examples of the extended music video and key moments of the British independent video art movement. Countless artists and broadcasters have emulated or outright stolen the ambitions, aesthetics and techniques used in the videos of The Nocturnal Emissions, either directly or through watered-down copies - few however can match the tremendous power of the original works which are long overdue public and critical reassessment in these increasingly pertinent times.

Free entry with small donations welcomed. Doors open at 7:30. A short talk and introduction by the organiser will precede the first video at 8pm - second video will be shown after 9pm. Please be aware that these videos contains flashing images and some footage that may disturb those of a sensitive disposition.

Special thanks to Nigel Ayers/Earthly Delights and Piitu Lintunen for making this event possible.

*Wharf Chambers Co-operative Club is a members’ club, and you need to be a member, or a guest of a member, in order to attend. To join, please visit wharfchambers.org. Membership costs £1 and requires a minimum of 48 hours to take effect.*"

http://www.earthlydelights.co.uk/
http://nocturnalemissions.bandcamp.com/
http://www.nigelayers.com/

Here’s a simple trick that I recently rediscovered when I worked on a boot time reduction project for a customer. It’s not rocket science, but you may not be aware of it.

Our customer was using fbv to display its logo right after the system booted. This is a way to show that the system is available while you’re starting the system’s main application:

fbv -d 1 /root/logo.bmp > /dev/null 2>&1

With Grabserial and using simple instrumentation with messages issued on the serial console before and after running the command, we found that this command was taking 878 ms to execute. The customer’s system had an AT91SAM9263 ARM SOC from Atmel, running at 200 MHz.

Even if fbv is a simple program (22 KB on ARM, compiled with shared libraries), decoding the logo image is still expensive. Here’s a way to get this compute cost out of your boot sequence. All you have to do is display your logo on your framebuffer, and then capture the framebuffer contents in a file:

fbv -d 1 /root/logo.bmp cp /dev/fb0 /root/logo.fb

The new file is now a little bigger, 230400 bytes instead of 76990. However, displaying your boot logo can now be done by a simple copy:

dd if=/root/logo.fb of=/dev/fb0 bs=230400 count=1 > /dev/null 2>&1

This command now runs in only 54 ms. That’s only 6% of the initial execution time! The advantage of this approach is that it works with any kind of framebuffer pixel format, as long as you have at least one program that knows how to write to your own framebuffer.

Note that the dd command was used to read and write the logo in one shot, rather than copying in multiple chunks. We found that the equivalent cp and cat commands were slightly slower. Of course, the benchmark results will vary from one system to another. Our customer had heavily optimized their NOR flash access time. If you run this on a very slow storage device, using a much faster CPU, the time to display the logo may be several impacted by the time taken to read a bigger file from slower storage.

To get even better performance, another trick is to compress the framebuffer contents with LZO (supported by BusyBox), which is very fast at decompressing, and requires very little memory to run:

lzop -9 /root/logo.fb

The new /root/logo.fb.lzop file is now only 2987 bytes big. Of course, the compression rate will depend on your logo image. In our case, the splashscreen contains mostly white space and a simple monochrome company logo. The new command to put in your startup scripts is now:

lzopcat /root/logo.fb.lzo > /dev/fb0

The execution time is now just 52.5 ms! With a faster CPU, the time reduction would have been even bigger.

The ultimate trick for having a real and possibly animated splashscreen would be to implement your own C program, directly writing to the framebuffer memory in mmap() mode. Here’s a nice tutorial showing how easy it can be.

Note: this article was first written for the German edition of Linux Magazine, and was later posted in the English edition too. We negotiated the right to publish it on our blog after the print editions. Here is the original version (the paper versions were modified by the editors to make them more concise).

In the family tree of computers, personal computers (PCs) are the parents, while the children and teenagers are mobile devices. PCs are no longer physically attractive, getting close to retirement. They produce a lot of heat, and make all sorts of unpleasant noise when you are next to them. Noise is caused by keyboard presses, by fans that are essential to avoid computer meltdown, and by rotating disks that sound like nothing but something that rotates.

The last chance for this generation to survive a few more years is to send them to a remote place where nobody can see their old bodies and hear their annoying noise any more. This place is called The Cloud. Perhaps because it gets these systems closer to the final destination: heaven.

If you have a device that you feel like putting on your knees (without getting burned) and caress its skin (oops screen), and doesn’t make any noise but the pleasant sounds that you feel like listening too, chances are you have a device from the last generation.

One reason why your device doesn’t make any unwanted sound is because it doesn’t have rotating disks, but flash storage instead. Most modern devices have flash storage, and most of these devices run Linux. This article gives technical details about how Linux supports flash storage devices. It should mostly interest people creating embedded and multimedia devices using the Linux kernel to get the best performance out of their hardware. People who wish to hack the devices they own should be interested too.

Flash storage

Flash storage, also called solid state, has multiple advantages over rotating storage. First, the absence of mechanical and moving parts eliminate noise, increase reliability and resistance to shock and vibrations, and also reduces heat dissipation as well as power consumption. Second, random access to data is also much faster, as you no longer have to move a disk head to the right location on the medium, which can take milliseconds.

Flash also has its shortcomings, of course. First, for the same price, you have about 10 times less solid state storage than rotating storage. This can be an issue with operating systems that require Gigabytes of disk space. Fortunately, Linux only needs a few MB of storage. Second, writing to flash storage has special constraints. You cannot write to the same location on a flash block multiple times without erasing the entire block, called an “erase block”. This constraint can also cause write speed to be much lower than read speed. Third, flash blocks can only withstand a rather limited number of erases (from a few thousand for today densest NAND flash to one million at best). This requires to implement hardware or software solutions, called “wear leveling”, to make sure that no flash block gets written to much too often that the others.

NOR flash was the first type of flash storage that was invented. NOR is very convenient as it allows the CPU to access each byte one by one, in random order. This way, the CPU can execute code directly from NOR flash. This is very convenient for bootloaders, which do not have to be copied to RAM before executing their code.

NAND flash is today’s most popular type of flash storage, as it offers more storage capacity for a much lower cost. The drawback is that NAND storage is on an external device, like rotating storage. You have to use a controller to access device data, and the CPU cannot execute code from NAND without copying the code to RAM first. Another constraint is that NAND flash devices can come out of the factory with faulty blocks, requiring hardware or software solutions to identify and discard bad blocks.

Two types of NAND flash storage are available today. The first type emulates a standard block interface, and contains a hardware “Flash Translation Layer” that takes care of erasing blocks, implementing wear leveling and managing bad blocks. This corresponds to USB flash drives, media cards, embedded MMC (eMMC) and Solid State Disks (SSD). The operating system has no control on the way flash sectors are managed, because it only sees an emulated block device. This is useful to reduce software complexity on the OS side. However, hardware makers usually keep their Flash Translation Layer algorithms secret. This leaves no way for system developers to verify and tune these algorithms, and I heard multiple voices in the Free Software community suspecting that these trade secrets were a way to hide poor implementations. For example, I was told that some flash media implemented wear leveling on 16 MB sectors, instead of using the whole storage space. This can make it very easy to break a flash device.

The second type is raw flash. The operating system has access to the flash controller, and can directly manage flash blocks. Counting the number of times a block has been erased is also possible (“block erase count”). The Linux kernel implements a Memory Technology Device (MTD) subsystem that allows to access and control the various types of flash devices with a common interface. This gives the freedom to implement hardware independent software to manage flash storage, in particular filesystems. Freedom and independence is something we have learned to care about in our community.

The Linux MTD architecture

Linux MTD partitions

The first thing you can do is access raw flash storage and partitions. It is similar to accessing raw block devices through devices files like /dev/sda (whole device) and /dev/sda1, /dev/sda2, etc. (partitions).

MTD devices are usually partitioned. This is useful to define areas for different purposes, such as:

Example MTD partitions

Raw means that no filesystem is used. This is not needed when you just have one binary to store, instead of multiple files.

Declaring partitions as read-only is also a way to make sure that Linux won’t allow to make changes to such partitions. This way, the bootloader and root filesystem partitions can be protected against mistakes and unauthorized modification attempts. You can also note that partitions cannot be bypassed by accessing the whole device at a given offset, as Linux offers no device file to access the whole storage.

What’s special in MTD partitions is that there is no partition table as in block devices. This is probably because flash is an unsafe location to store such critical system information, as flash blocks may become bad during system life.

Instead, partitions are defined in the kernel. An example is found in the arch/arm/mach-omap2/board-omap3beagle.c file in the kernel sources, defining flash partitions for the Beagle board:

static struct mtd_partition omap3beagle_nand_partitions[] = { /* All the partition sizes are listed in terms of NAND block size */ { .name = "X-Loader", .offset = 0, .size = 4 * NAND_BLOCK_SIZE, .mask_flags = MTD_WRITEABLE, /* force read-only */ }, { .name = "U-Boot", .offset = MTDPART_OFS_APPEND, /* Offset = 0x80000 */ .size = 15 * NAND_BLOCK_SIZE, .mask_flags = MTD_WRITEABLE, /* force read-only */ }, { .name = "U-Boot Env", .offset = MTDPART_OFS_APPEND, /* Offset = 0x260000 */ .size = 1 * NAND_BLOCK_SIZE, }, { .name = "Kernel", .offset = MTDPART_OFS_APPEND, /* Offset = 0x280000 */ .size = 32 * NAND_BLOCK_SIZE, }, { .name = "File System", .offset = MTDPART_OFS_APPEND, /* Offset = 0x680000 */ .size = MTDPART_SIZ_FULL, }, };

Fortunately, you can override these default definitions without having to modify the kernel sources.

You first need to find the name of the MTD device to partition, as you may have multiple ones. Look at the
kernel log at boot time. In the Beagle board example, the MTD device name is omap2-nand.0:

omap2-nand driver initializing ONFI flash detected NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit) Creating 5 MTD partitions on "omap2-nand.0": 0x000000000000-0x000000080000 : "X-Loader" 0x000000080000-0x000000260000 : "U-Boot" 0x000000260000-0x000000280000 : "U-Boot Env" 0x000000280000-0x000000680000 : "Kernel" 0x000000680000-0x000010000000 : "File System"

Fortunately, you can define your own partitions without having to modify the kernel sources. The Linux kernel offers an mtdpartss boot parameter to define your own partition boundaries.

You can now add an mtdparts definition to the kernel command line (change it through the bootloader):

Example:

mtdparts=omap2-nand.0:128k(X-Loader)ro,256k(U-Boot)ro,128k(Environment),4m(Kernel)ro,32m(RootFS)ro,-(Data)

We have just defined 6 partitions in the omap2-nand.0 device:

• First stage bootloader (128 KiB, read-only)
• U-Boot (256 KiB, read-only)
• U-Boot environment (128 KiB)
• Kernel (4 MiB, read-only)
• Root filesystem (16 MiB, read-only)
• Data (remaining space)

Note that partition sizes must be a multiple of the erase block size. The erase block size can be found in /sys/class/mtd/mtdx/erasesize on the target system.

Now that partitions are defined, you can display the corresponding MTD devices by viewing /proc/mtd (the sizes are in hexadecimal):

dev: size erasesize name mtd0: 00020000 00020000 "X-Loader" mtd1: 00040000 00020000 "U-Boot" mtd2: 00020000 00020000 "Environment" mtd3: 00400000 00020000 "Kernel" mtd4: 02000000 00020000 "File System" mtd5: 0dbc0000 00020000 "Data"

Here, you can also see another difference with block devices. Device files names for block device partitions still refer to the complete device name (for example /dev/sda1 for the first partition of the device represented by /dev/sda). MTD partitions are shown as independent MTD devices, and for example mtd1 could either be the second partition of the first flash device, or the first partition of the second flash device. You cannot tell the difference from device names.

Back to our example, you can see that a separate flash partition is dedicated to storing the U-Boot environment variables. Did you know that you can update these variables from Linux, by flashing an image for this partition? At Free Electrons, we have contributed a utility to create such an image.

Manipulating MTD devices

You can access MTD device number X through two types of interfaces. The first interface is a /dev/mtdX character device, managed by the mtdchar driver. In particular, this character device provides ioctl commands that are typically used by mtd-utils commands to manipulate and erase blocks in an MTD device.

The second interface is a /dev/mtdblockX block device, handled by the mtdblock driver. This device is mostly used to mount MTD filesystems, such as JFFS2 and YAFFS2, because the mount command primarily works with block devices. You may be tempted to use this device to write to the MTD device, but the corresponding driver isn’t elaborate enough for use in production. When you attempt to write to a given block, the previous contents are copied to RAM, the MTD block is erased, and the updated contents are written to the block. As you can see, there is no wear leveling of any sort, as a series of writes to the same part of the block device could very quickly damage the corresponding erase blocks. Worse, mtdblock isn’t even bad block aware. If you copy a filesystem image directly to /dev/mtdblockX, and your NAND storage has bad blocks, your filesystem will be corrupted because of the failure to write parts of the filesystem image.

Therefore, the clean way to manipulate MTD devices is through the character interface, and using the mtd-utils commands. Here are the most common ones:

• mtdinfo to get detailed information about an MTD device
• flash_eraseall to completely erase a given MTD device
• flashcp to write to NOR flash
• nandwrite to write to NAND flash
• UBI utilities (see later)
• Flash filesystem image creation tools: mkfs.jffs2, mkfs.ubifs

These commands are available through the mtd-utils package in GNU/Linux distributions and can also be cross-compiled from source by embedded Linux build systems such as Buildroot and OpenEmbedded. Simple implementations of the most common commands are also available in BusyBox, making them much easier to cross-compile for simple embedded systems.

JFFS2

Journaling Flash File System version 2 (JFFS2), added to the Linux kernel in 2001, is a very popular filesystem for flash storage. As expected in a flash filesystem, it implements bad block detection and management, as well as wear leveling. It is also designed to stay in a consistent state after abrupt power failures and system crashes. Last but not least, it also stores data in compressed form. Multiple compressing schemes are available, according to whether matters more: read/write performance or the compression rate. For example, zlib compresses better than lzo, but is also much slower.

Implementing flash filesystems has special constraints. When you make a change to a particular file, you shouldn’t just go the easy way and copy the corresponding blocks to RAM, erase them, and flash the blocks with the new version. The first reason is that a power failure during the erase or write operations would cause irrecoverable data loss. The second reason is that you could quickly wear out specific blocks by making multiple updates to the same file.

Another solution is to copy the new data to a new block, and replace references to the old block by references to the new block. However, this implies another write on the filesystem, causing more references to be modified until the root reference is reached.

JFFS2 uses a log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See log-structured approach to address this problem. Each file is described through a “node”, describing file metadata and data, and each node has an associated version number. Instead of making in-place changes, the idea is to write a more recent version of the node elsewhere in an erase block with free space. While this simplifies write operations, this complicates read ones, as reading a file requires to find the most recent node for this file.

To optimize performance, JFFS2 keeps an in-memory map of the most recent nodes for each file. However, this requires to scan all the nodes at mount time, to reconstitute this map. This is very expensive, as JFFS2′s mount time is proportional to the number of nodes. Embedded systems using JFFS2 on big flash partitions incurred big boot time penalties because of this. Fortunately, a CONFIG_JFFS2_SUMMARY kernel option was added, allowing to store this map on the flash device itself and dramatically reduce mount time. Be careful, this option is not turned on by default!

Back to node management, older nodes must be reclaimed at some point, to keep space free for newer writes. A node is created as “valid” and is considered as “obsolete” when a newer version is created. JFFS2 managed three types of flash blocks:

• Clean blocks, containing only valid nodes
• Dirty blocks, containing at least one obsolete node
• Free blocks, not containing any node yet

JFFS2 runs a garbage collector in the background that recycles dirty blocks into free blocks. It does this by collecting all the valid nodes in a dirty block, and copying them to a clean block (with space left) or to a free block. The old dirty block is then erased and marked as free. To make all the erase blocks participate to wear leveling, the garbage collector occasionally consumes clean blocks too. See Wikipedia for more details about JFFS2.

There are two ways of using JFFS2 on a flash partition. The first way is to erase the partition and format it for JFFS2, and then mount it:

flash_eraseall -j /dev/mtd2 mount -t jffs2 /dev/mtdblock2 /mnt/flash

Note that flash_eraseall -j both erases the flash partition and formats it for JFFS2. You can then fill the partition by writing data into it.

The second way, which is more convenient to program production devices, is to prepare a JFFS2 image on a development workstation, and flash this image into the partition:

flash_eraseall /dev/mtd2 nandwrite -p /dev/mtd2 rootfs.jffs2

To prepare the JFFS2 image, you need to use the mkfs.jffs2 command supplied by mtd-utils. Do not be confused by its name: unlike some other mkfs commands, it doesn’t create a filesystem, but a filesystem image.

You first need to find the erase block size (as explained earlier). Let us assume it is 256 MiB.

Then create the image on your workstation:

mkfs.jffs2 --pad --no-cleanmarkers --eraseblock=256 -d rootfs/ -o rootfs.jffs2

• -d specifies is a directory with the filesystem contents
• --pad allows to create an image which size is a multiple of the erase block size.
• --no-cleanmarkers should only be used for NAND flash.

It is fine to have a JFFS2 image that is smaller than the MTD partition. JFFS2 will still be able to use the whole partition, provided it was completely erased ahead of time.

Note that to prepare production devices, it is much more convenient to flash your MTD partitions from the bootloader, using a bad block aware command, without having to boot Linux. This way, you do not have to put development utilities such as flash_eraseall in the Linux root filesystem. This is another reason why filesystem images are useful. You typically download the filesystem image to RAM through the network, and then copy the image to flash. When you do this, just make sure that you copy the exact image size. With kernel images, we often copy a bigger number of bytes from RAM to flash, as the exact image size can vary, and this creates no issue. With JFFS2 images, if you copy more bytes from RAM to flash, you will end up writing flash with random bytes from RAM after the end of your image, which will corrupt the filesystem. I’m warning you because this is a typical mistake the people make during our training sessions.

YAFFS2

YAFFS2 is Yet Another Flash Filesystem which apparently was created as an alternative to JFFS2. It doesn’t use compression, but features a much faster mount time, as well as better read and write performance than JFFS2. YAFFS2 is available with a dual GPL and Proprietary license, GPL for use in the Linux kernel, and proprietary for proprietary operating systems. Revenue from the proprietary license allowed the fund the development of this filesystem.

YAFFS2 less popular than JFFS2, and this is probably because it is not part of the mainline Linux kernel. Instead, it is available as separate code with scripts to patch most versions of the Linux kernel source. There was an effort to get it mainlined about one year ago, but this attempt failed because the changes the kernel maintainers asked for would have broken the portability to other operating systems, and therefore would have compromised the project business model.

See Wikipedia for implementation details.

To use YAFFS2 after patching your kernel, you just need to erase your partition:

flash_eraseall /dev/mtd2

The filesystem is automatically formatted at the first mount:

mount -t yaffs2 /dev/mtdblock2 /mnt/flash

It is also possible to create YAFFS2 filesystem images with the mkyaffs tool, from yaffs-utils.

UBI and UBIFS

JFFS2 and YAFFS2 had a major issue: wear leveling was implemented by the filesystems themselves, implying that wear leveling was only local to individual partitions. In many systems, there are read-only partitions, or at least partitions that are very rarely updated, such as programs and libraries, as opposed to other read-write data areas which get most writes. These “hot” partitions take the risk of wearing out earlier than if all the flash sections participated in wear leveling. This is exactly what the Unsorted Block Images (UBI) project offers.

UBI is a layer on top of MTD which takes care of managing erase blocks, implementing wear leveling and bad block management on the whole device. This way, upper layers no longer have to take care of these tasks by themselves. UBI also supports flexible partitions or volumes, which can be created and resized dynamically, in a way that is similar to the Logical Volume Manager for block devices.

UBI works by implementing “Logical Erase Blocks” (LEBs), mapping to “Physical Erase Blocks” (PEBs). The upper layers only see LEBs. If an LEB gets written to too often, UBI can decide to swap pointers, to replace the “hot” PEB by a “cold” one. This mechanism requires a few free PEBs to work efficiently, and this overhead makes UBI less appropriate for small devices with just a few MB of space.

UBI Physical and Logical Erase Blocks

UBIFS is a filesystem for UBI. It was created by the Linux MTD project as JFFS2′s successor. It also supports compression and has much better mount, read and write performance.

The first way to use UBIFS is to initialize UBI from Linux:

• Have /dev/ mounted as a devtmpfs filesystem
• Erase your flash partition while preserving your erase counters ubiformat /dev/mtd1
• Attach UBI to one (of several) of the MTD partitions: ubiattach /dev/ubi_ctrl -m 1

  This command creates the ubi0 device, which represents the full UBI space stored on MTD device 1 (interfaced by a new /dev/ubi0 character device).

• Create one or several volumes as in the below examples: ubimkvol /dev/ubi0 -N test -s 116MiB ubimkvol /dev/ubi0 -N test -m (max available size)
• Mount an empty UBIFS filesystem on the new test volume: mount -t ubifs ubi0:test /mnt/flash
• You can then fill the filesystem by copying files to it
• Note that it is also possible to create a UBIFS filesystem image with the mkfs.ubifs command and copy the image using ubiupdatevol.

The second way is to create an image of the entire UBI space, which can be flashed from the bootloader by a bad block aware command. To do this, first create a ubi.ini file describing the UBI space, its volumes and their contents. Here is an example:

[RFS-volume] mode=ubi image=rootfs.ubifs vol_id=1 vol_size=30MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize vol_alignment=1

You can then create the UBI image, for example specifying 128 KiB physical erase blocks and a minimum I/O size of 4096 bytes:

ubinize -o ubi.img -p 128KiB -m 4096 ubi.ini

The last steps are to flash the image file from the bootloader, using a bad block aware command, and add some parameters to the kernel command line:

• ubi.mtd=1 (equivalent to ubiattach)
• rootfstype=ubifs root=ubi0:rootfs if you use the UBIFS volume as root filesystem.

LogFS

As its name says, LogFS is another log-structured flash filesystem. It has an innovative design that could compete with UBIFS, and is now part of the mainline Linux kernel since version 2.6.34.

Unfortunately, the last time we tested it, LogFS was unstable and caused kernel oopses at unmount time. Therefore, we couldn’t compare it with the other filesystems. Being in the mainline Linux sources makes its code easier to maintain and fix though, and the bugs may be fixed in the latest kernel version when you read this article.

More details about LogFS can be found on Wikipedia.

SquashFS

For read-only partitions, it is actually possible to use the SquashFS block filesystem on MTD devices. My first idea was to directly copy a SquashFS image to the corresponding /dev/mtdblockx device. After all, this filesystem is read-only, and you don’t need any wear-leveling of any kind, as you never make any write. This worked very well, and I got very good performance results, until I tried to use SquashFS on a device that happened to have bad blocks. Remember that the mtdblock driver isn’t bad block aware. As a consequence, the SquashFS images didn’t get copied properly and the filesystem was corrupted. A bad block aware block device was therefore required.

There are two ways to do this. It is first possible to use the gluebi driver that emulates an MTD device on top of a UBI volume. As UBI discards bad blocks, it is then safe to use the mdtblock driver on top of this new MTD device.

A second possibility is to use the ubiblock driver (first submitted to the Linux Kernel Mailing List in 2011 by Free Electrons, and revived by Ezequiel Garcia in November 2012, which implements a block device directly on top of UBI. Our benchmarks showed that this is a more efficient solution, as it doesn’t have to emulate an intermediate MTD device).

Benchmarks

Free Electrons has run performance benchmarks to compare the various flash filesystems, with funding from the Linux foundation. The benchmarks and their results are described on eLinux.org.

These benchmarks showed that JFFS2 has the worst performance, and must absolutely be compiled with CONFIG_SUMMARY to have an acceptable boot time. However, JFFS2 is still the best compromise for devices with small flash partitions, for which compression is required, and where UBI would have too much space overhead. This is the reason why JFFS2 is still in use in OpenWRT, a distribution mainly targeting embedded devices like residential gateways and routers, with typically 4 to 16 MB of flash storage.

YAFFS2, thanks to improvements in the last years, shows very good if not best performance in many test scenarios. However, its drawbacks remain the lack of compression and its absence from the mainline Linux kernel sources. It also has weird performance issues managing directories.

UBIFS is now the best solution in terms of performance and space, except for small partitions in which its space overhead is significant. Its only drawback is that it requires a bit more work to deploy, compared to the other filesystems.

At the time of this writing, LogFS is too experimental to be used in production systems, though you can expect its bugs to be fixed over time, as its code is in the mainline kernel sources.

Last but not least, SquashFS can also be used on MTD flash, in systems with read-only partitions. This filesystem exhibits good compression, good mount time, and good read performance as well. The requirement to use SquashFS on top of UBI impairs its mount time performance though. On block filesystems, SquashFS exhibits the best mount time, but it looses a lot of time when it is on top of UBI, which takes a substantial amount of time to initialize (ubiattach operation).

The good news is that it is very cheap to switch filesystems. Applications won’t notice the difference. As our benchmarks have shown, you may get noticeable performance results, according to the size of your partitions, to the size and number of files, to the read and write patterns of your system, and to whether your files can be compressed or not. All you have to do is try the various filesystems, run your application and system tests, and keep the solution that maximizes performance for your particular system.

Back to flash storage with a block interface

We have seen the MTD subsystem and several filesystems allowing for complete control on the way flash blocks are managed. This allows to choose the wear leveling and block management scheme that best matches the various characteristics of the system.
But what to do when you are stuck with flash storage with a block interface, like SD cards for example? With these devices, you have no details about the erase block size and about the wear leveling algorithm. While these media are fine for external storage which just get occasional writes, you may run into deep trouble if you use these as primary storage in a system with intense I/O operations.

This issue is getting all the more critical as NAND flash is being replaced by eMMC in many recent embedded boards. eMMC is NAND flash with an MMC interface, but as opposed to MMC, is soldered on the board, to be immune from reliability issues caused by vibrations. The main advantage of eMMC is its unit price, making it more attractive than individual NAND chips produced in smaller quantities. Another advantage is that the block device is immediately available at boot time, without requiring any intervention and scanning from the operating system. Not having to manage bad blocks and wear leveling also keeps software simpler, of course at the cost of less control as we said. Some board makers, for example the engineers at CALAO Systems, even predict the extinction of raw flash in the next years. Raw flash may just be kept for specific industrial applications, but would then get very expensive because of low production volume.

Fortunately, we are not completely stuck with no clue about the internals of such flash devices. Arnd Bergmann has studied cheap flash media and has developed flashbench, a benchmarking tool to find their erase block size. This allows to optimize file system settings and get huge performance boosts on these flash media, and reduce the number of block erases. Arnd has described is work in a very interesting article on LWN.net.

Other than that, you are still stuck with an opaque wear leveling mechanism, and it’s always wise to use techniques to minimize the number of writes:

• Do not put a swap area on flash storage
• Whenever possible, mount your filesystems as read-only, or use read-only filesystems (SquashFS)
• Keep volatile files such as log files and locks in RAM (tmpfs). You do not need to keep them across reboots anyway, and you do not want to create unnecessary disk activity because of them.

Conclusions and what to remember

If you develop or hack a device with raw flash, your best option is to use the JFFS2 filesystem for small partitions, with the CONFIG_SUMMARY option. For medium to very large partitions, UBIFS will be the best compromise in terms of speed, size and boot time. However, you may get slightly better performance with YAFFS2, but at the expense of size.

If you have a device with only flash storage with a block interface, for example an SD card, download flashbench from Arnd Bergmann and optimize the settings of your filesystems to get the best performance out of your storage, and optimize its lifetime.

If you reached this part of the article, you have the patience and interest required to contribute to the MTD subsystem of the Linux kernel. Contributions, code reviews and new ideas are welcome!

Useful resources

• Wikipedia’s page on flash memory
• Linux-MTD project FAQ: A gold mine about MTD, its filesystems and its utilities, which answered most of my questions.
• Free Electrons embedded Linux training materials including a presentation on block and flash filesystems, together with practical labs.

We have delivered two seminars about Android during the last quarter of 2012. The seminars were held in Belfort and Grenoble, France, and were organized by Captronic, a French public program to support innovation in electronic systems.

This one day seminar targets people who wish to understand the constraints and implications of using Android in embedded products, and know the steps to follow. The seminar is led by Maxime Ripard, Free Electrons’ Android expert. Maxime is also the creator of Free Electrons’ Android system development course.

Agenda Morning

• General introduction to Android
• Opportunities to use Android in embedded systems which are neither phones nor tablets
• Details on Android’s architecture and how to customize it:
  • Source code and compiling
  • Android changes to the Linux kernel
  • Bootloaders for Android
  • Supporting new hardware
  • Android filesystem layout
  • Android native layers and calling a C program to access specific hardware
  • Introduction to application development
  • Customizing the system
  • Using adb (Android Debug Bridge) for debugging and device remote access
  • Advice and resources

Afternoon

• Completing the morning presentations (if necessary)
• Demonstrating multiple aspects of system development with Android:
  • Getting sources and compiling
  • Android emulator demonstration
  • Starting Android on an electronic board with an ARM OMAP3530 processor, using a serial console.
  • Adding support for specific buttons. “Back” button example.
  • Using adb: installing, accessing system logs, accessing a command line interface on the device, exchanging files with the PC.
  • Customizing the system: change the product name, the default wallpaper, add new properties.
  • To access specific hardware (such as a USB device), development of a native library and accessing this functionality from the Android framework through a specific class and JNI library.
  • Describing an application that allows to control a USB device.
  • Questions and answers

Presentation slides

Presentation slides are available in PDF and LaTeX source formats. As usual, they are released under the terms of the Creative Commons Attribution – ShareAlike 3.0 license. This means that you can reuse and modify them according to your own needs.

If you are interested in having one of us run such a seminar on your own part of the world, giving the audience the opportunity to ask all the questions they can have on the use of Android in embedded systems, don’t hesitate to contact us.

If you are by any chance in Vienna on the 24th Feb. – I would like to invite you to a talk i am giving within the Solidarity-based Economy Congress 2013. I will be talking about the Open Technologie Labratory and the OggStreamer Project. The experiences from the past years and how these two project benefited from each other. The short description reads as follows:

OpenHardware and open workshops as tools for experimental exploration of alternative economic models

Field report and thought-provoking impulses from 3 years of work on two projects. The first project, called OTELO, aims at the installation of open workshops in rural areas. The second project, called OggStramer, is an electronic OpenHardware product. It was developed with the support of many friendly people within the OTELO Vöcklabruck, where it became a production-ready device. This development was made possible due to the OTELO framework, which served as space, network and source of inspiration. With this lecture we want to tell the story of these projects to show, that complex ventures (regardless their nature) are possible with the support of a community.

Date: Sunday, 24th Feb 2013 – Time: 11:00 – 12:30

So I did some visuals for Known Ocean at Sprawl, please forgive the shaky one handed photography, I was 'playing the Chromascope pretty heavily for this performance using a few tricks only a factory modified unit like mine can do such as removing removing sync for glitchy effects, ect.