How Linux became a mobile phone OS (LinuxDevices) [LWN.net]

How Linux became a mobile phone OS (LinuxDevices)

Posted Aug 16, 2007 23:06 UTC (Thu) by ncm (subscriber, #165) [Link]

Despite the PR-speak, there's an unusual amount of meat to the article.

What I found missing was any discussion of controversy. For example, it's not universally agreed upon that execute-from-ROM is a Good Idea. RAM is cheaper than Flash, so you may be better off keeping compressed code in Flash and uncompressing it into RAM and running it from there. Phone hardware designers may not have got the memo, though, and so put in more Flash and less RAM than good judgment would dictate. Or, maybe, they know that Flash doesn't need to be powered when it's unused, and are working under a limited power budget.

Power is the #1 criterion

Posted Aug 16, 2007 23:25 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Cell phone makers will do just about anything to cut power and squeeze out a bit more battery life.

How Linux became a mobile phone OS (LinuxDevices)

Posted Aug 17, 2007 15:05 UTC (Fri) by xav (subscriber, #18536) [Link]

RAM is cheaper than Flash

The article tells exactely the inverse.

How Linux became a mobile phone OS (LinuxDevices)

Posted Aug 20, 2007 14:54 UTC (Mon) by jonth (subscriber, #4008) [Link]

RAM is also a _lot_ faster than flash. Running directly from flash is almost as bad an idea as running directly from disk.

Whoops

Posted Aug 16, 2007 23:31 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

I goofed, Ready is the CTO of MontaVista, not the chairman.

A lot missing from this piece

Posted Aug 17, 2007 8:41 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

Jim Ready is an old hand in embedded systems, having founded several generations of companies. I remember Hunter-Ready and Ready Systems before Monte Vista. But I agree with the other commentator that this piece is somewhat self-serving of his company and even inaccurate in some ways.

Execute-in-place sounds good but turns out not to be very desirable in an embedded device. Not only is FLASH more expensive than RAM, which merits that you compress its contents rather than execute them in place, but FLASH is much slower to access than RAM and costs more power to access. And it does not make economic sense to put external FLASH on a wide bus - that makes the chip cost more and have a higher pin count, and ties up pins that would otherwise be used for IOs on the CPU and thus drives up the CPU pin count too, and makes your PC board more complicated and larger. So, it ends up working better for the executable to live in a compressed filesystem and for it to be paged from there to RAM.

Also, the power-saving features are still lagging in the Linux kernel - they have often been built for embedded processors but haven't really been done well enough to make it into the main kernel tree. So, we are really just getting to the point that drivers know how to suspend properly, and in theory we can shut down a part of the memory and power it off, and a bus, but this code is better exercised on large enterprise machines than embedded systems.

But Linux has been a good system for embedded use in that it's been both small and very feature-full, since about 1996 or so. When I wrote Busybox, I could get a complete command-line environment and the kernel on a single 1.44MB floppy that would boot a PC and start the Debian installer. The kernel has gotten bigger since then, but it's still quite comfortable for embedded use on modern machines.

Bruce

A lot missing from this piece

Posted Aug 17, 2007 10:20 UTC (Fri) by epa (subscriber, #39769) [Link]

What happened to good old ROM? I thought it could be accessed fast, didn't require much power when the machine is on and none when it's off. Have ROM speeds not kept pace with RAM? Surely most embedded devices never get a software upgrade anyway.

A lot missing from this piece

Posted Aug 17, 2007 10:36 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

Things have changed since the 2708 :-) . Most ROM these days is slower than RAM, simply because the technology to get the bits to the CPU quickly is more expensive in terms of transistors, traces, etc., than the bits themselves. And ROM is not that useful unless you're making something really simple like a mouse.

Imagine that you are a manufacturer faced with a bug in your device. The bug may inconvenience your customers and hurt your reputation. It may expose you to a class-action lawsuit (not uncommon for consumer devices). It may be a copyright infringement that you have to remedy by replacing code in the device - or by paying the copyright holder more than you'd like.

You have two choices if you have to change the code in a large number of devices in the field. Push some sort of in-the-field update to them, or recall them. If you recall them, expect it to cost Millions, and you will have news coverage, and your stock will take a hit. If you field-update the devices, it'll probably be cheap and you'll look really good. My TomTom seems to do a field update quite often when I plug it into their (MS Windows, alas) desktop software. Most phones come with a PC cable or they just have a USB jack these days, and they come with some sort of desktop sync product. So, such an field update would hardly be a problem for those devices.

Bruce

Re problems with ROM

Posted Aug 17, 2007 15:11 UTC (Fri) by PO8 (guest, #41661) [Link]

But fixed ROM should still read faster than flash, should it not? The traditional solution for the ROM upgrade problem is providing hooks; code in ROM is linked through jump tables in RAM so that defective code in ROM can be substituted with code in flash on an incremental basis...

Re problems with ROM

Posted Aug 17, 2007 16:24 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

Well, look in the Digi-Key catalog for OTP EPROMs with parallel outputs rather than some sort of one-wire bus. Most of them are 8 bits wide, and the response times are per byte, not word, start at 200 ns and go down to 44 ns. If you put 4 of those chips in parallel you might get bandwidth that matches your internal RAM, for a lot of wires and a lot of money. The prices do not make them realistic compared with the cost of a large 1-wire FLASH and the internal RAM of some embedded processor.

Thanks

Bruce

Re problems with ROM

Posted Aug 17, 2007 18:32 UTC (Fri) by jeff@uclinux.org (guest, #8024) [Link]

Mask ROM requires you to make a mask for at least 1 metal layer. The costs are huge and the minimum quantity to buy is too. It's still done in products where it makes sense for the economy of scale, but you had really better be sure that your code is right before you commit. Mask ROMs I've seen have an async bus... slow.

The last time I used Execute in Place for an embedded linux system was probably around 2000. It made sense... at that time uClinux fit in about 1.5Meg of FLASH, kernel and userland. We had been doing that since 1996. It doesn't make a lot of sense now in most practical applications for all the reasons Bruce mentions. To give you some idea, NOR FLASH has only increased in density by a few times since then and not at all (practically speaking) in speed. There is just no way to keep the processor in a cell phone, even a slow one (say, 166MHz) fed with instructions from a 70nS NOR FLASH. The odd uncommon synchronous FLASH not withstanding.

Re problems with ROM

Posted Aug 17, 2007 20:51 UTC (Fri) by BrucePerens (subscriber, #2510) [Link]

Perhaps you could explain to these folks how NAND FLASH is different from NOR and why random access isn't built into those chips. I've only heard the explanation once and might get it wrong.

Thanks

Bruce

Re problems with ROM

Posted Aug 18, 2007 17:27 UTC (Sat) by jeff@uclinux.org (guest, #8024) [Link]

NAND FLASH is structured into an array of pages. Each page is of fixed size, for instance 2kbytes + 64bytes. The 64 "extra" bytes are ECC, and that's the reason it can be made cost effective. NAND FLASH isn't designed to be perfect, instead you error detect and correct. You read a page at a time, clocking each byte out in order, then correct (and possibly mark bad) the whole block. You can't execute in place from a block based device. That also means you can't boot your CPU from it... you need a little bootstrap ROM with code to access the NAND FLASH or a little hardware state machine to read a boot block from the NAND FLASH. Have a look at wikipedia to see why it's called NAND and why that implies pages and higher density... and I mean a lot higher in density. Remember that chip defect density is specified in defects / unit area. A typical NAND FLASH today is 512 Mbyte or 1Gbyte, a really large (possibly imperfect) die.

In contrast NOR FLASH has to be perfect. That said, redundant structures that can be used to replace bad blocks at the factory and improve manufacturing yield. It is random access, no errors (looking from the outside) are acceptable, the data must be available after a fixed period of time in whatever order it's addressed. The typical NOR FLASH today is 2 or 4 Mbyte... smaller die, higher percentage of perfect (or correctable with redundant blocks) chips.

Bottom line: NAND FLASH is for bulk storage and NOR FLASH code storage. NAND FLASH is what you find in Smart Media and xD Card (just a raw die in a card shaped package) and in SD card (coupled with a built-in controller).